How best to organise a multitargeted VS solution being ported from .net Framework to both .net Framework+Core?

Question

I'm not a native English speaker, and i'm new to .net Core.

I have a task to port the logic of a WPF app to .Net Core while leaving this app working like previously. The app has approximately 70 Visual Studio assemblies:

• Say, 40 of them are related to logic and must become cross-platform.
• Say, about 20 of the logic-related assembles use WCF or Clipboard or other things that do not work on .Net Core.

I'm going to create the new solution from scratch. This solution should have assembles targeting .Net Framework, .Net Core, and both Framework+Core.

But how is it best to organise this new solution?

Should I have 3 Solution Folders/Categories of assembles:

• Framework Assembles
• Core Assembles
• Multitargeted Assembles

?

Implying that:

• the numbers above are correct
• each of the 20 logic-related assembles with things that do not work on .Net Core fall into 3 new assembles (Core, Framework, MultiTargeted)
• the core-only assemblies implement the same features in .net Core as in framework or just contain stubs or NotImplementedExceptions

, the amount of assembles in the end should be: 30 + 20 + 20*3 = 110 in this case.

UPD: I'm aware of the possibility of using conditional compilation via directives, therefore having 1 assembly instead of three. I'm not sure, but i have a preconception that this is not a nice approach (adds mess to code).

UPD2: More about compiler directives: Are Compiler Directives an Antipattern?

Thanks!

Answer 1

I would start with the simple thing: Make a distinction between your libraries and executables. The simplest thing is to have all your libraries target NetStandard. The version of NetStandard you use depends on what level of compatibility you need (reference).

• Microsoft.Net 4.6.1 -> can use up to NetStandard 2.0
• NetCore 1.x -> can use up to NetStandrd 1.6
• NetCore 2.0 -> can use NetStandard 2.0

Understand that with every higher level of NetStandard is more support for standard APIs. You will be forced to make some changes to your library code, and explicitly reference the assemblies you need. NetStandard is built around more granular APIs. The nice thing is that your libraries can be used in both NetCore apps and Microsot.Net framework apps without multi-targeting. You have more capabilities than the older PLC libraries.

Bottom line is that if you are using supported versions of .Net, you can use some version of the NetStandard library. The benefits of this approach are:

• That gets rid of the need to multi-target or work with conditional compilation
• It allows you to use the very same assembly in both net-core and Framework apps
• It allows you to take advantage of the NuGet support built in to the new project structure, including building and deploying NuGet libraries to a local repository.