Assembly Loading in a mixed framework environment
See original GitHub issue[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:
- 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>
- 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
orAssembly.LoadFrom
method. - 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.
- 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.
- 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).
- Identifying missing dlls. There is still no fuslogvw tool (or similar) to identify failed bindings.
- 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?
Issue Analytics
- State:
- Created 6 years ago
- Comments:12 (4 by maintainers)
Top Results From Across the Web
Best Practices for Assembly Loading - .NET Framework
Explore best practices for assembly loading in .NET. Avoid problems of type identity that can lead to invalid casts, missing methods, ...
Read more >Assemblies in .NET
Assemblies are the fundamental units of deployment, version control, reuse, activation scoping, and security permissions for .
Read more >Dynamically Loading Types in .NET Core with a Custom ...
An assembly load context gives us control over how assemblies are loaded. In this case, we can give instructions on where to find...
Read more >Mixed Assemblies - Crafting Flexible C++ Reflective ...
Mixed Assemblies may be loaded from disk using the Reflection API, but not from memory. The Assembly.LoadFrom and Assembly.LoadFile functions ...
Read more >Mixing .NET 3.5 with 4/4.5 assemblies in the same process
CLR takes care to redirect .NET Framework assemblies to those that have the same version number as the runtime that is loaded in...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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:
Thanks
@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