Build and project patterns when targeting .NET Core and .NET Framework flavors?

Question

We've got a solution with 20 .NET Framework 4.5 .DLLs (say helloworld01.dll to helloworld20.dll) where we want to add Linux support (to each) in the near future. We think this means each of those needs to be recompiled as .NET Core 1.0 targets.

Leaving source code porting aside and only looking at the organization/structure, what's the recommended practice to develop, build and release .NET Core 1.0 flavors alongside the .NET Framework DLLs?

• Entirely new .sln file + parallel folder structure for code?
• New project file each + parallel folder structure for code?
• New project file each + references into existing folder structure?
• Same project file + same folder structure + some msbuild based black magic? (I suspect not given the xml vs json proj files)
• some other wizardry?

Bonus: Can you point to the open-source project that embodies such best practices?

Answer 1

Provided that the libraries that the code uses in each DLL is available in both the full framework (4.5+) and .NET Core. Then you can actually setup one project that compiles a DLL accessible to both frameworks by targeting .NET Standard.

This is possible even with .NET Standard 1.6 (i.e. you don't need to wait for 2.0). The key is that there is still a lot of functionality from the full framework that is not yet available in .NET Core, and closing that gap is what .NET Standard 2.0 is about.

The Project JSON for a class library that can be accessed by other projects of different targets should look something like this:

{
 "version": "1.0.0-*",
 "frameworks": {
 "net462": {
 "dependencies": {
 }
 },
 "netstandard1.6": {
 "imports": "dnxcore50"
 }
 },
 "dependencies": {
 "NETStandard.Library": "1.6.0",
 "System.ComponentModel.Annotations": "4.3.0",
 "System.ComponentModel.Primitives": "4.1.0",
 "System.Reflection.TypeExtensions": "4.3.0-preview1-24530-04"
 }
}

Hope that helps.

Answer 2

The problems my team is facing are new and also acknowledged by the .NET team. They will be addressing it in .NET Core "vNext" (1.2?).

That's when we'll have many features enabling side by side releases of .NET Framework and .NET core libraries such as:

• MSBuild support in .NET Core
• Ability to use csproj for .NET Core (related to above)
• Ability to reference .NET Core DLLs from .NET F/W projects (and vice versa)

More stuff but the above would really streamline the use case in the question. So the answer is ...

Wait for .NET Standard 2.0

• Robert Harvey: @replies don't work in answers. Also, you've answered your question, but you haven't really explained why or how this works (other than you believe it will streamline your specific use case) for the benefit of others reading this post.