Reputation: 7217
I have a package that is built using .net Standard 2.0. I want to be able to utilise it in both .net Framework and .net Core applications but it has the following line of code:
using System.Runtime.Loader;
…
AssemblyLoadContext.Default.Unloading += (ctx) => ProcessStop();
…
This doesn't work for the .net Framework (seems like the System.Runtime.Loader is a core only package). I can omit it at compile time using this sort of statement:
#if NETCOREAPP2_0 || NETCOREAPP2_1
AssemblyLoadContext.Default.Unloading += (ctx) => ProcessStop();
#endif
Which doesn't help me when the package is compiled already and I want to use it in .net Framework. Anyone know how to do this sort of thing inline?
Thanks for any pointers in advance!
Upvotes: 4
Views: 1349
Reputation: 411
It seems that there is an issue with AssemblyLoadContext
(or the System.Runtime.Loader package to be precise) according to https://github.com/dotnet/cli/issues/6019
The package claims to support .NET-Framework (and netstandard1.5) but apparently doesn't. So yes, System.Runtime.Loader seems to be a core-only package - what absolutely perverts the concept of .NET-Standard in my opinion...
The consequence of this now is, that the .NET-Standard 2.0 package you mentioned does not really support .NET-Standard 2.0, but .NET-Core >= 1.0 (from the System.Runtime.Loader point of view). I don't see any chance to make an already compiled version without that mentioned switch work with .NET-Framework.
Anyone know how to do this sort of thing inline?
When providing the mentioned library as NuGet-package, there is the posibility to extract runtime-specific implementations to runtime-specific DLLs: https://learn.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks But this, of course, implies recompiling the package.
Upvotes: 2