Use .NET Core with legacy .NET framework dlls

Question

Can I use .NET Core with legacy .NET Framework dlls? The answer seems to be no... but I can only find resources referring to project.json, which doesn't exist anymore.

I created a new .NET core library and tried to reference a legacy .NET framework DLL. When I tried to call into the DLL, VS 2017 complained that I didn't have the Stream object is was looking for.

It suggested I reference either mscorlib.dll or install a NuGet package.

The quick help failed to reference mscorlib.dll. If I manually referenced it, I get the following error:

The type 'TargetFrameworkAttribute' exists in both 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' and 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' C:\Users...\AppData\Local\Temp.NETCoreApp,Version=v1.1.AssemblyAttributes.cs

The NuGet package is Microsoft.NETFx2.0. The quick help fails to install it. If I run it from the command line:

> PM> install-package microsoft.netfx20   GET
> https://api.nuget.org/v3/registration2-gz/microsoft.netfx20/index.json
> OK
> https://api.nuget.org/v3/registration2-gz/microsoft.netfx20/index.json
> 46ms Restoring packages for ... Install-Package : Package
> Microsoft.NetFX20 1.0.3 is not compatible with netcoreapp1.1
> (.NETCoreApp,Version=v1.1). Package Microsoft.NetFX20 1.0.3 supports:
> net20 (.NETFramework,Version=v2.0)At line:1 char:1
> + install-package microsoft.netfx20
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
>     + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
> Install-Package : One or more packages are incompatible with
> .NETCoreApp,Version=v1.1.At line:1 char:1
> + install-package microsoft.netfx20
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
>     + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
> Install-Package : Package restore failed. Rolling back package changes
> for .At line:1 char:1
> + install-package microsoft.netfx20
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
>     + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
> Time Elapsed: 00:00:00.8035644

Answer 1

I am not sure what the compatibility shim the other answers are referring to is but, as of .NET Core 2, you can directly reference a .NET Framework dll in a .NET Core project.

Note that a .NET Framework dll might be using some Windows specific APIs so you might lose out on the cross-compatibility of .NET Core. But, if you're just looking to upgrade to a newer version of C# (since they are now only available on newer versions of .NET Core and .NET), it won't matter that much. If you're on .NET 5 or newer, you might want to use the Windows TFM net5.0-windows to make sure your project is only built for Windows.

If the .NET Framework dll is using certain Windows APIs that are not available in .NET Core, then you can reference the Microsoft.Windows.Compatibility NuGet package (more info here, and here).

Answer 2

Difficult topic. Generally .NET Framework and .NET Core are incompatible. They target a different set of assemblies (mscorlib vs. System.Runtime) which causes incompatibilities since all usages of types are prefixed with the assembly the type is from.

Starting with .NET Core 2 (currently in preview), you can reference .NET Framework assemblies through an invisible compatibility shim. This allows you to reference the assembly and compile successfully.

It doesn't guarantee though that the application will run successfully, since .NET Core doesn't provide all the APIs from .NET Framework. You'll get PlatformNotSupportedException or MissingTypeException and friends at runtime if that's the case.

Answer 3

Building on top of Suchiman's answer, the compatibility shim will allow a .NET Core application to reference .NET Framework libraries and succeed at compile time but the .NET Core application may fail at run time if any required underlying .NET Framework libraries are missing.

To improve the chances of success at run time, you can try using the Windows Compatibility Pack. This basically attempts to fill in missing .NET Framework libraries. The downside is that the Windows Compatibility Pack is somewhat specific to Windows so it may affect the cross-platform compatibility of the .NET Core app.