-
Notifications
You must be signed in to change notification settings - Fork 26
Description
When the .Net code is launched from pythonnet, the TargetFrameworkName
property of the AppDomain.SetupInformation
is not configured / provided.
Here is what AppDomain setup information returns from the normally executed .Net code:
AppDomain setup information:
AppDomainManagerAssembly = NULL
AppDomainManagerType = NULL
ApplicationBase = D:\_WorkRoot\Clients\...\bin\Debug\
ConfigurationFile = D:\_WorkRoot\Clients\...\bin\Debug\UPSTest.exe.Config
TargetFrameworkName = .NETFramework,Version=v4.8
DynamicBase = NULL
DisallowPublisherPolicy = False
DisallowBindingRedirects = False
DisallowCodeDownload = False
DisallowApplicationBaseProbing = False
ApplicationName = UPSTest.exe
PrivateBinPath = NULL
PrivateBinPathProbe = NULL
ShadowCopyDirectories = NULL
ShadowCopyFiles = NULL
CachePath = NULL
LicenseFile = NULL
LoaderOptimization = NotSpecified
SandboxInterop = False
Here is how it is setup when called from PythonNet:
AppDomain setup information:
AppDomainManagerAssembly = NULL
AppDomainManagerType = NULL
ApplicationBase = C:\Program Files\Python310\
ConfigurationFile = C:\Program Files\Python310\python.exe.Config
TargetFrameworkName = NULL
DynamicBase = NULL
DisallowPublisherPolicy = False
DisallowBindingRedirects = False
DisallowCodeDownload = False
DisallowApplicationBaseProbing = False
ApplicationName = python.exe
PrivateBinPath = NULL
PrivateBinPathProbe = NULL
ShadowCopyDirectories = NULL
ShadowCopyFiles = NULL
CachePath = NULL
LicenseFile = NULL
LoaderOptimization = NotSpecified
SandboxInterop = False
Why is it important? The below is the copy of the .Net 4.7.2 code that uses that moniker inside AppContext
class (system\AppContext\AppContextDefaultValues.cs
) (added in .Net 4.6.2).
internal static partial class AppContextDefaultValues
{
public static void PopulateDefaultValues()
{
string platformIdentifier, profile;
int version;
ParseTargetFrameworkName(out platformIdentifier, out profile, out version);
// Call into each library to populate their default switches
PopulateDefaultValuesPartial(platformIdentifier, profile, version);
}
/// <summary>
/// We have this separate method for getting the parsed elements out of the TargetFrameworkName so we can
/// more easily support this on other platforms.
/// </summary>
private static void ParseTargetFrameworkName(out string identifier, out string profile, out int version)
{
string targetFrameworkMoniker = AppDomain.CurrentDomain.SetupInformation.TargetFrameworkName;
// If we don't have a TFM then we should default to the 4.0 behavior where all quirks are turned on.
if (!TryParseFrameworkName(targetFrameworkMoniker, out identifier, out version, out profile))
{
#if FEATURE_CORECLR
if (CompatibilitySwitches.UseLatestBehaviorWhenTFMNotSpecified)
{
// If we want to use the latest behavior it is enough to set the value of the switch to string.Empty.
// When the get to the caller of this method (PopulateDefaultValuesPartial) we are going to use the
// identifier we just set to decide which switches to turn on. By having an empty string as the
// identifier we are simply saying -- don't turn on any switches, and we are going to get the latest
// behavior for all the switches
identifier = string.Empty;
}
else
#endif
{
identifier = ".NETFramework";
version = 40000;
profile = string.Empty;
}
}
}
The AppContext
switches control behavior of number of .Net components (between versions). For example, one of such switches controls behavior of asymmetric encryption. It may mean that any code that calls .Net API impacted by any of those switches will behave differently inside Python than what is expected by the .Net code author.
It creates uncertainties for the .Net code that calls such .Net Framework API. For example, we are trying to detect which level of compatibility we are currently under to call our encryption code accordingly. That determination includes TargetFramework of the entry assembly or supportedRuntime element in the config file. And our code might not have a proper recovery strategy to go all the way back to .Net 4.0 compatibility (yet having installed all the latest .Net and compiled using latest .Net Framework).
Some switches are explictely controllable via configuration file but missing framework in the AppDomain setup just opens the mine field of discrepancies.