Currently it's possible that the host (hostpolicy) will pass duplicate runtime properties to CoreCLR upon initialization. This can happen if the app/framework specifies some property in its .runtimeconfig.json and then hostpolicy sets a value for the same property (since it's one of the properties which hostpolicy sets).
The current behavior is that the runtime property array will simply have two records for the same property name in this case. CoreCLR will fail with such input. The properties are processed early on in CorHost2::_CreateAppDomain https://github.com/dotnet/coreclr/blob/5d57b87227b7fd116735edf9f5f75b3154953d8e/src/vm/corhost.cpp#L705
This calls into AppContext.Setup which will simply iterate over all properties and call Dictionary.Add on them: https://github.com/dotnet/coreclr/blob/5d57b87227b7fd116735edf9f5f75b3154953d8e/src/System.Private.CoreLib/src/System/AppContext.CoreCLR.cs#L16
If there are duplicates the dictionary will throw and exception, which this early in the property leads to runtime initialization failure reported as an HRESULT to hostpolicy.
The proposal is to check for duplicates in hostpolicy before passing the properties to the runtime. And if there are duplicates fail. This provides a more robust host implementation (doesn't pass invalid data to the runtime) and will allow us to potentially improve this area in the future. For example we may provide ways for the native host to implement some conflict resolution without introducing additional breaking changes.
Technically this is a breaking change as the failure mode would be somewhat different (different output to stderr, and different error code returned by hostpolicy). But that's the only observable difference, the duplicate properties always lead to a failure.
Note that this change only applies to hostpolicy and thus only to .NET Core 3.0, it would not affect down-level versions.
Currently it's possible that the host (
hostpolicy) will pass duplicate runtime properties to CoreCLR upon initialization. This can happen if the app/framework specifies some property in its.runtimeconfig.jsonand thenhostpolicysets a value for the same property (since it's one of the properties whichhostpolicysets).The current behavior is that the runtime property array will simply have two records for the same property name in this case. CoreCLR will fail with such input. The properties are processed early on in
CorHost2::_CreateAppDomainhttps://github.com/dotnet/coreclr/blob/5d57b87227b7fd116735edf9f5f75b3154953d8e/src/vm/corhost.cpp#L705This calls into
AppContext.Setupwhich will simply iterate over all properties and callDictionary.Addon them: https://github.com/dotnet/coreclr/blob/5d57b87227b7fd116735edf9f5f75b3154953d8e/src/System.Private.CoreLib/src/System/AppContext.CoreCLR.cs#L16If there are duplicates the dictionary will throw and exception, which this early in the property leads to runtime initialization failure reported as an HRESULT to
hostpolicy.The proposal is to check for duplicates in
hostpolicybefore passing the properties to the runtime. And if there are duplicates fail. This provides a more robust host implementation (doesn't pass invalid data to the runtime) and will allow us to potentially improve this area in the future. For example we may provide ways for the native host to implement some conflict resolution without introducing additional breaking changes.Technically this is a breaking change as the failure mode would be somewhat different (different output to
stderr, and different error code returned byhostpolicy). But that's the only observable difference, the duplicate properties always lead to a failure.Note that this change only applies to
hostpolicyand thus only to .NET Core 3.0, it would not affect down-level versions.