natemcmaster/DotNetCorePlugins

Self contained apps do not have a runtime graph

natemcmaster opened this issue · 3 comments

Describe the bug
The .NET Core SDK trims the RID graph for self-contained apps. This means self contained apps cannot correctly interpret deps.json and RIDs.

To Reproduce

  1. Create a host app that is self contained.
  2. Create a plugin which uses a dependency that has rid-specific assets, such as System.Drawing.Common

Expected behavior
Plugins do not need to know about the RID used by the host, and vice versa.

Additional context

The .NET Core SDK makes the assumption that self-contained applications know about their dependencies at build-time, and it does some trimming to remove information it thinks won't be needed at runtime. Some of the information trimmed is the runtime identifier fallback graph. This means when this section of code runs, it cannot find a runtime graph so fallbackGraph = { "any" }.

var ridGraph = dependencyContext.RuntimeGraph.Any()
? dependencyContext.RuntimeGraph
: DependencyContext.Default.RuntimeGraph;
var rid = Microsoft.DotNet.PlatformAbstractions.RuntimeEnvironment.GetRuntimeIdentifier();
var fallbackRid = GetFallbackRid();
var fallbackGraph = ridGraph.FirstOrDefault(g => g.Runtime == rid)
?? ridGraph.FirstOrDefault(g => g.Runtime == fallbackRid)
?? new RuntimeFallbacks("any");

For example: when it is reading the deps.json file, the runtime does not know how to handle the "win" runtime identifer.

          "runtimes/win/lib/netcoreapp2.0/System.Drawing.Common.dll": {
            "rid": "win",
            "assetType": "runtime",
            "assemblyVersion": "4.0.0.1",
            "fileVersion": "4.6.26919.2"
          }

Options:

  • Embed a copy of the RID graph in McMaster.NETCore.Plugins.dll (acquired from Microsoft.NETCore.Platforms)
    • Downside: everytime the RID graph changes, we'd need a new version of this library. For example, every time macOS releases a new verison, or a new type of Linux gains support for .NET Core
  • Dynamically find the RID graph at build time and embed in the app.
    • Downside: Since the SDK doesn't do this, we'll have to include some build magic in the targets for this library to preserve the RID graph into a resource embedded in the app
  • Add API and let users specify the RID graph programmatically.
    • Downside: this is just cruel.

See also these related issues in .NET Core dotnet/sdk#1046 and https://github.com/dotnet/core-setup/issues/1846

stale commented

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please comment if you believe this should remain open, otherwise it will be closed in 7 days.