Enable RID-specific Apps on Shared Framework #1053
Conversation
This option enables a RID-specific application to still use the shared framework.
Allow .NET Core applications to be RID-specific, but still run on the Shared Framework. This enables an application to carry only the native assets it needs for the specific runtime it intends to run on. For example, if an application uses a graphics library and wants to run on the shared framework, it would carry that graphics library for all the runtimes the graphics library supported (win, osx, linux, x86, x64, arm, etc). But if the application is only intended to run on one runtime, these extra assemblies bloat the app.
| _projectContext.LockFileTarget.RuntimeIdentifier, | ||
| runtimeSignature, | ||
| _projectContext.IsPortable); | ||
| isPortable: string.IsNullOrEmpty(_projectContext.LockFileTarget.RuntimeIdentifier)); |
There was a problem hiding this comment.
Why do we use the RID check here but plumb IsSelfContained elsewhere?
There was a problem hiding this comment.
I need to add a comment here.
Basically, IsPortable != IsFrameworkDependent and IsPortable != !IsSelfContained.
But IsFrameworkDependent == !IsSelfContained. (for now until we add some other app model where it doesn't run on a shared framework and still isn't self-contained.)
IsPortable means your app can run on any machine. It is portable across architectures, OSes, etc.
IsFrameworkDependent means your app runs on the shared framework, but it can still be runtime-specific. note: IsPortable implies IsFrameworkDependent
IsSelfContained means everything required to run your app is located in your publish output.
In this case, DependencyModel is strictly asking for IsPortable, not IsFrameworkDependent or !IsSelfContained. And looking under the hood, DependencyModel treats IsPortable and an empty RuntimeIdentifier the same. In a perfect world, this boolean wouldn't be needed to be passed here.
There was a problem hiding this comment.
Thanks for the thorough explanation.
Add a comment for DependencyContext IsPortable usage.
After dotnet/sdk#1053 is merged, it is possible for an app to run on the shared framework, but not be "portable". DependencyContextLoader should always load the "runtime" context, if it is present. Also, with #1597, there may be other deps files for the app. It should load those as well. Fix #1886
|
@nguerrera @dsplaisted - can you take a look? I'd like to get this merged today. |
| runtime, | ||
| Constants.DefaultPlatformLibrary); | ||
| Constants.DefaultPlatformLibrary, | ||
| false); |
There was a problem hiding this comment.
Please use named arguments for bools.
| runtime, | ||
| Constants.DefaultPlatformLibrary); | ||
| Constants.DefaultPlatformLibrary, | ||
| false); |
| if (isFrameworkDependent) | ||
| { | ||
| Debug.Assert(platformLibrary != null); | ||
| } |
There was a problem hiding this comment.
Debug.Assert(!isFrameworkDependent || platformLibrary != null) ?
There was a problem hiding this comment.
I kind of like the readability of the way it is. It is very straight-forward to understand (at least to me). The compiler will remove the if statement in release mode, since it is empty, so it isn't like it will affect the outputted assembly code.
Do you have a strong opinion on this?
There was a problem hiding this comment.
I don't have a strong opinion.
This is necessary because of dotnet/sdk#1053
This is necessary for dotnet/sdk#1053
This flows to the $(SelfContained) property added in dotnet/sdk#1053
This flows to the $(SelfContained) property added in dotnet/sdk#1053
…0191030.11 (dotnet#1053) - Microsoft.AspNetCore.Analyzers - 3.1.0-preview3.19530.11 - Microsoft.AspNetCore.Mvc.Api.Analyzers - 3.1.0-preview3.19530.11 - Microsoft.AspNetCore.Mvc.Analyzers - 3.1.0-preview3.19530.11 - Microsoft.AspNetCore.Components.Analyzers - 3.1.0-preview3.19530.11
4 participants
Allow .NET Core applications to be RID-specific, but still run on the Shared Framework. This enables an application to carry only the native assets it needs for the specific runtime it intends to run on.
For example, if an application uses a graphics library and wants to run on the shared framework, it would carry that graphics library for all the runtimes the graphics library supported (win, osx, linux, x86, x64, arm, etc). But if the application is only intended to run on one runtime, these extra assemblies bloat the app.
@ericstj @nguerrera @dsplaisted @livarcocc
/cc @Petermarcu
Notes:
There are 2 other changes that need to go into other repos:
--self-contained[:false|true], which flows into the MSBuild$(SelfContained)property added here.A future, potential scenario is to publish self-contained, but don't specify any RID. This won't work today because
dotnet restorehasn't restored for that RID, thus the necessary assets are not available. This can be revisited when restore occurs during publish. For now, that scenario raises an error with a message saying it is unsupported.