5 ms·

Is it possible to load ".NET Framework" assemblies into ".NET 6" applications? (We have a lot of .NET Framework libraries, shared between different application

Is it possible to load ".NET Framework" assemblies into ".NET 6" applications? (We have a lot of .NET Framework libraries, shared between different applications, and a complex dependency graph between them. So I'm wondering if it is possible to migrate away from .NET Framework by starting with the executables and working our way down the dependency graph.)

my123 5y ago
No, you can however have .NET Standard assemblies that can load into both .NET (Core) and .NET (old) applications. Those use a common API subset, and are a stopgap to make migration easier.
geewee 5y ago
Yes if you can migrate them to .netstandard2.0 you can run them on both .net framework and the newer core/.net5/6 releases. I've just done this exact migration path myself for a legacy application
MaXtreeM 5y ago
Others have said no, but I think you can. The ".NET Framework compatibility mode"[0][1] was introduced in netcore2.0 (which actually is now quite a long ago, geez), which means that if your libraries don't use some windows-specific APIs/functionality, like WPF, there is a big chance that you can use them just as they are. I have never used my own .NET framework library like that but I think have used some 3rd party library targeting .NET framework in production. [0]: https://docs.microsoft.com/en-us/dotnet/core/porting/third-party-deps#net-framework-compatibility-mode https://docs.microsoft.com/en-us/dotnet/core/porting/third-p... [1]: https://docs.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode https://docs.microsoft.com/en-us/dotnet/core/porting/#net-fr...
koyote 5y ago
Yes you can, you simply add them as project references. We have done this in production and it works quite well. You have to be careful though because you could get runtime crashes if they try to access stuff that is not supported in .NET 6 (mostly Windows-specific libraries). I'd recommend running this guy on the code base, it'll give you a good idea of how much a pain it will be: https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer https://docs.microsoft.com/en-us/dotnet/standard/analyzers/p...

my123 5y ago

No, you can however have .NET Standard assemblies that can load into both .NET (Core) and .NET (old) applications. Those use a common API subset, and are a stopgap to make migration easier.

geewee 5y ago

Yes if you can migrate them to .netstandard2.0 you can run them on both .net framework and the newer core/.net5/6 releases. I've just done this exact migration path myself for a legacy application

MaXtreeM 5y ago

Others have said no, but I think you can. The ".NET Framework compatibility mode"[0][1] was introduced in netcore2.0 (which actually is now quite a long ago, geez), which means that if your libraries don't use some windows-specific APIs/functionality, like WPF, there is a big chance that you can use them just as they are. I have never used my own .NET framework library like that but I think have used some 3rd party library targeting .NET framework in production. [0]: https://docs.microsoft.com/en-us/dotnet/core/porting/third-party-deps#net-framework-compatibility-mode https://docs.microsoft.com/en-us/dotnet/core/porting/third-p... [1]: https://docs.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode https://docs.microsoft.com/en-us/dotnet/core/porting/#net-fr...

koyote 5y ago

Yes you can, you simply add them as project references. We have done this in production and it works quite well. You have to be careful though because you could get runtime crashes if they try to access stuff that is not supported in .NET 6 (mostly Windows-specific libraries). I'd recommend running this guy on the code base, it'll give you a good idea of how much a pain it will be: https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer https://docs.microsoft.com/en-us/dotnet/standard/analyzers/p...