Remove all runtime properties from frameworks #13844
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The way we produce a shared framework is by simulating a build of an application (to certain degree), running lot of the code from SDK which is meant to build apps.
This includes the part which generates
.runtimeconfig.jsonfor the framework.Starting with .NET 6, SDK sets some runtime config options by default of console apps. Because of this process these options became part of the
.runtimeconfig.jsonfor the framework. In .NET 6 we shipped with one such property (System.Reflection.Metadata.MetadataUpdater.IsSupported). In .NET 8 we've added another oneSystem.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization).The problem with these options is that the SDK sets them to different values based on which type of app it builds. For example, the
System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerializationshould befalsefor console apps, but it should betruefor WindowsDesktop apps (at least for now).The shared framework is common to all application types though, and so it should not set any values for these options as it can't know the appropriate default.
This change removes all runtime options before we generate the
.runtimeconfig.json. If we ever need to include a runtime option in a shared framework, it will have to be added after this removal - this change doesn't introduce any such mechanism for now.To double check:
As far as I can tell there is no existing framework to test shared framework creation, and this change seems small enough to warrant adding an entire infra for it.
I validated that building the
Microsoft.NETCore.Appframework in dotnet/runtime with this change applied locally doesn't produce any runtime options into the `.runtimeconfig.json.This should resolve the problem in dotnet/sdk#32969 (once it flows to runtime and from runtime to sdk/installer).