Assembly Loading in a mixed framework environment

[This is just a discussion / brainstorming] Let’s say there is a scenario with:

• An App running either with netstandard or netcoreapp
• A common netstandard dll defining an interface
• A number of plugins, either netstandard or netstandard, that are NOT directly referenced by the App

The discussion is about the best solution and/or the missing runtime and tools to ease developer’s life.

Here there are my points:

1. When the App declare multiple frameworks there is currently no way from VS2017 to choose the runtime to debug with <TargetFrameworks>netcoreapp1.1;net462</TargetFrameworks>
2. The AssemblyLoadContext is netcore specific even if it is inside the System.Runtime.Loader nestandard dll. This means I am required to if/endif in C# code to pick the AssemblyLoadContext.Default.LoadFromAssemblyPath or Assembly.LoadFrom method.
3. When I want to load a plugin, I also need to know if its framework is compatible with the one the App is actually running (either nestandard or netcoreapp). 3a. What is the best way to identify the current running framework? 3b. How can I identify the framework used from a dll? I tried with metadata but I could not find any info (see here https://github.com/dotnet/corefx/issues/17309.
4. Identifying plugin dependencies. I need to deploy separately the App and the plugins (that can come from 3rd parties). This means that every plugin should be able to be shipped with all the required dependencies (as it already happens when you deploy an app with Self-Contained Deploying SCD). There is no current tooling in VS2017 or in the CLI to copy in a folder the required library dependencies. The deps.json file can be a starting point but a tool is required as the content may vary depending on the runtimes as well.
5. When I manually load the plugin, its dependencies cannot be found automatically from the loader. For example If I reference System.Net.Ping 4.3 nuget package the runtime will look for System.Net.Ping.dll 4.0.1 (or similar). The only way to make the runtime load the plugin is to intercept the AssemblyResolving event (and AssemblyResolve for netstandard).
6. Identifying missing dlls. There is still no fuslogvw tool (or similar) to identify failed bindings.
7. If both the App and the plugin references, for example, System.IO package but in different versions, what is the best practice for managing version differences? The first (App) win? Or what?

A draft for a netstandard/netcoreapp loader is here

[raffaeler]

The fuslogvw trace all the binding resolution steps: the folders where the assembly is looked for, and if it is found traces the version mismatch and the exact reason why the version cannot be loaded. Extending the current trace with these info can be enough … does this make sense to you?

Also, could you please give me the link with COREHOST_TRACE documentation is? I know there are other valuable variables like DOTNET_CLI_CAPTURE_TIMING but I don’t find the docs. I would like:

• the complete list of the variables
• what each value does (I could find people setting COREHOST_TRACE to 3 instead of 1)

Thanks

[sherlockkong]

@raffaeler I mean Assembly.LoadFrom works fine on ubuntu16.04, so I replaced AssemblyLoadContext.Default.LoadFromAssemblyPath with Assembly.LoadFrom.

But I do not know if Assembly.LoadFrom works fine in all situations. Have you ever encountered a situation where Assembly.LoadFrom does not work properly?

Thanks