Programmatically resolving shared frameworks

[natemcmaster]

Is there any API to programmatically resolve a shared framework's location? I found an API for resolving SDKs (hostfxr_resolve_sdk2), but no equivalent for shared frameworks.

Scenarios

The scenarios I had in mind for this API are:

• Create tools which can identify which shared framework would be loaded, and if compatible framework is found, alert the user that it will be necessary to install a shared framework.
• Be able to write an assembly load context to workaround this limitation: https://github.com/dotnet/core-setup/blob/90ba7b628ff397caa35c50e8ecbf50f96308d1c3/Documentation/design-docs/host-component-dependencies-resolution.md#frameworks-handling

cc @vitek-karas @dagood

[vitek-karas]

There's no such API currently. We're considering something similar here #3290 , not exactly the same, but maybe useful.

@natemcmaster do you have some more details for the scenarios you mention?

• For the tools - something like an installer? So basically something similar to dotnet --info but in an API
• What scenario you have in mind which runs into the limitation in the AssemblyDependencyResolver? It's technically possible to remove that limitation, but so far I was not able to come up with a valid scenario which would really need something like that.

Also - what would you expect the API to take as input? Some version spec, or path to .runtimeconfig.json, or something else? The framework resolution in 3.0 is relatively complex as there might be a tree of frameworks (ASP.NET and UI both depending on NetCore), I'm not sure it would be easy to provide an API which would work as expected and only take some kind of simple input.

[natemcmaster]

For the tools

Two examples:

• dotnet tool install. I'd love to improve this SDK command. Right now, it will install global tools which can't run, but you don't know an app won't run until you try to launch it. It would be great if dotnet tool install could run a check post-install that instruct customers when additional installation steps will be necessary to make a tool run.
• Hosting a website - when running, ASP.NET Core in IIS, websites often fails with HTTP 502.5 if the customer has pointed their app to a version of .NET Core which has not yet been deployed to the hosting server. I'd love to create a tool for hosting providers like Azure Web Sites which allows us to implement a pre-deployment gate that ensures a compatible runtime will be available.

For input, I can imagine two overloads being useful, one that takes a runtimeconfig.json file, and another which takes the same parameters which can be expressed in runtimeconfig.json. If I were writing this in C#, something like this

readonly struct SharedFrameworkVersionSpec
{
	public string Name { get; }
	public string Version { get; }
}

readonly struct SharedFrameworkInstallation
{
	public string Name { get; }
	public string Version { get; }
	public string Directory { get; }
}

enum SharedFrameworkRollForwardPolicy
{
    SameMajorMinor,
    SameMajor,
    Any
}

SharedFrameworkInstallation[] ResolveFrameworks(SharedFrameworkVersionSpec[] frameworks, SharedFrameworkRollForwardPolicy rollForwardPolicy = SharedFrameworkRollForwardPolicy.SameMajor, bool applyPatches = true);
SharedFrameworkInstallation[] ResolveFrameworks(string runtimeConfigPath, bool loadDevConfig = true);

What scenario you have in mind which runs into the limitation in the AssemblyDependencyResolver?

This was a request made in natemcmaster/DotNetCorePlugins#19. The customer wants to write a simple console tool (only depends on Microsoft.NETCore.App) which can dynamically load a component which depends on assemblies found in other shared frameworks, like AspNetCore or Windows Desktop. Given current limitations, it seems the only solution to reference all known shared frameworks for the console tool which does the loading.

[vitek-karas]

Thanks a lot @natemcmaster .

I personally would be fine with:

• API which lists all the frameworks available (like dotnet --info, but API), there has been other requests for this already. Not ideal for the "install" scenario, but might be workable.
• The API proposed above which takes .runtimeconfig.json and returns paths to the resolved frameworks (probably would need some more tweaks to correctly support self-contained apps).
• The API proposed in Proposal: hostfxr_get_clr_properties to get all the information needed to self-host host a clr runtime. #3290 which returns the resolved TPA without actually running the app.

I would be very hesitant introducing an API which takes all the input in parameters like you proposed above. The problem is that it limits our options of adding new parameters to .runtimeconfig.json, or rather adding new options would simply make this API effectively obsolete.

The AssemblyDependencyResolver issue should probably be resolved as part of that class and not by adding new public APIs to the host, that just feels like a hacky workaround.

[natemcmaster]

The problem is that it limits our options of adding new parameters to .runtimeconfig.json

I agree, it's a non-trivial problem to solve. But I think there are some ways we could do this. IMO it's worth having an API. In the second scenario I described -- tools for hosting providers -- we may not have the runtimeconfig.json file yet. I'd like to see if we can design an API that's forward/backwards compatible and doesn't require me to serialize the API's parameters to a JSON file on disk.

[MarcoRossignoli]

@vitek-karas similar api could be useful also for us on coverlet https://github.com/dotnet/cli/issues/12705#issuecomment-539460359
In version less than 3.0(now lib are moved to output by design) sometimes we need to load lib from shared framework needed for instrumentation coverlet-coverage/coverlet#560

[vitek-karas]

In 3.0 we shipped API which can sort of do it by using a file. You could use hostfxr_initialize_for_runtime_config (this needs the runtimeconfing.json on disk to declare which framework you're looking for). After that returns you can then call hostfxr_get_runtime_property_value and as for "APP_CONTEXT_DEPS_FILES" which returns a list of all .deps.json files from all resolved frameworks. That way you can get the location of all resolved frameworks.

It's not very clean and the functions are not designed specifically for this usage, but it should work. The biggest downside is probably that this will actually load coreclr.dll into the process (although it will not start the runtime).

In any case this will only work on 3.0 and above (including the resolved frameworks, if this resolves 2.2 framework it will fail).

[MarcoRossignoli]

Understood...thank's for info...at the moment the issue is on users that run < 3.0
I'll try https://github.com/dotnet/cli/issues/12705#issuecomment-539519539

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.