CODEWITHSUNDEEP
c#.net-core-2.0.net-standard-2.0.net-4.7.1
StuffOfInterest
StuffOfInterest

Reputation: 518

Using .NET Standard library with Windows Compatibility Pack in .NET Framework

I'm working on migrating a large code base of libraries in a direction to eventually support .NET Core. Currently, everything is based on .NET Framework. I have a set of library projects which are consumed by several web applications.

The plan is to convert the library projects over to .NET Standard 2.0 so that they can be consumed by both .NET Framework (version 4.7.1) based websites and by new .NET Core (version 2.0) websites. I've done some test solutions which proved that this can be done.

To convert the first library over to .NET Standard I had to leverage the Windows Compatibility Pack for some of the features that are not part of .NET Standard. Some features such as SqlClient and some System.Drawing tools had to be imported into the library. All of this worked but an issue turned up when trying to bring my library into code which was still targeting .NET Framework.

Even though the namespaces were the same, the consuming code could not see the objects (such as Image or SqlConnection) unless I added the same Windows Compatibility Pack libraries into the consuming project. If anything, I would have expected this to cause issues as I now have two identical classes (same namespace and object name) in different assemblies. Fortunately, it is working. At least the unit tests are still passing.

Is this the way the Windows Compatibility Pack libraries are supposed to work? I had hoped that they would provide the functionality in the .NET Standard or .NET Core code but allow the .NET Framework to still use its own implementation.

Upvotes: 3

Views: 788

Answers (1)

Alex Ghiondea - MSFT
Alex Ghiondea - MSFT

Reputation: 3370

The compatibility package references a few of the assemblies that were brought back to increase the compatibility of .NET Core with .NET Framework.

The way the package works is that there is a meta-package (the one that you reference) and it has references to individual packages that actually contain the implementation. Those individual packages have different assets depending on the target framework.

Take for example System.IO.Ports. That package contains the following assets (and a few more things that are not directly relevant to this):

  • net461
  • netstandard2.0

The netstandard2.0 asset contains the code that implements the System.IO.Ports functionality. You will use this if you are building a .NET Core application.

The net461 asset type-forwards the types exposed by the System.IO.Ports namespace to the assemblies you will find in the .NET Framework installation. You will use these if you are building a .NET Framework application (like a console application of web site).

This means that when you are consuming your library on .NET Core, you are using the implementation that was ported and made to work on .NET Core.

When you are using your library on .NET Framework you will use the implementation that is part of .NET Framework.

Upvotes: 1

Related Questions