3

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.

StuffOfInterest
  • 518
  • 3
  • 11
  • No idea, but have you considered using conditional compilation instead? https://stackoverflow.com/questions/38040466/conditional-compilation-symbol-for-net-core-class-library –  Jan 17 '18 at 20:59
  • 1
    I've looked at multi targeting, but it appears there is some setup complexity there to fork the dependencies correctly to allow for both .NET Framework and .NET Standard targets to work with different sets of NuGet packages and framework library references. – StuffOfInterest Jan 17 '18 at 21:06
  • You've probably already found a solution, but here are some thoughts. I've done a larger migration (50 projects, 8 services) where the libraries were ported to .NET Standard, some services to ASP.NET Core targeting .NET Core, some targeting the full framework and a few were 'old' ASP.NET services. I managed the problems with indirect references and unnecessary coupling by abstracting away the functionality with interfaces and using dependency injection. – Iris Classon Mar 26 '18 at 20:20
  • Also, just wanted to add that the API Analyzer might come in handy to detect APIs not supported on all platforms (if your aim is cross platform). A pull request was merged in today to also scan Windows Compatibility Pack references, pull down the repo and compile the analyzer and add the DLLs manually or keep an eye out for the next release. https://github.com/dotnet/platform-compat . Here is a discussion w the PM re the analyzer and the compat pack https://twitter.com/IrisClasson/status/978293740736581632 . Have fun migrating, I know I had :D – Iris Classon Mar 26 '18 at 20:24
  • Windows Compatibility Pack should only be used in .NET Core apps, not .NET Standard class library IMHO. If you stick to that rule, then this problem won't happen initially. – Lex Li Apr 03 '18 at 22:51

1 Answers1

1

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.

Alex Ghiondea - MSFT
  • 3,182
  • 1
  • 8
  • 11