Using cross targeting to allow .NET Framework projects to reference .NET Core projects

TAB

Software consultant Matthew Clarke writes about how Visual Studio 2017’s cross targeting makes it easier to mix projects based on new technologies with existing code.

Our new wave of product development projects has been steaming ahead with the latest in Microsoft technologies: .NET Standard v2, .NET Core v2, ASP.NET Core v2, Entity Framework Core v2. Quite fittingly then, sometimes you need two target frameworks. It’s not possible to forget about the whole of the product’s legacy codebase and sadly it’s not possible to reference any code targeting these newer stacks from old versions of ‘full-fat’ .NET. So how do you write new components in the new technologies and let the old codebase reference them? Cross targeting!

A normal csproj file contains the following:

<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>

But make one subtle change and your library will be compiled for multiple platforms by magic:

<PropertyGroup>
<TargetFrameworks>net35;netstandard2.0</TargetFrameworks>
</PropertyGroup>

Although it still requires manually hacking the csproj (booooo!), this isn’t a new feature. It appears to have been introduced in Visual Studio 2010 in a more rudimentary manner. VS2017 has significantly improved the functionality and crucially added full conditional compilation support. It is now possible to use #if statements to control the compilation dependent on the target framework:

   loggerFactory.AddProvider(

      new DecoratedLoggerProvider(

         new OCCLoggerProvider(connstring, environmentInfo, stackTraceProcessor, OCCExceptionSerializer, detailsXmlGenerator,

#if NET462

         new EventLoggerProvider(new EventLogSettings() { SourceName = environmentInfo.ApplicationName }),

#endif

         new FileLoggerProvider(@".\logs\stdout\", environmentInfo, stackTraceProcessor, exceptionSerializer, detailsXmlGenerator)

In the example above, Event Logger logging is enabled when running on .NET 4.6.2, but not when running on .NET Core, as that platform doesn’t support the Event Logger. Before VS2017 this required creating custom Defines and the top Google results tell you to do just that. Now there’s a much simpler solution baked right into VS2017.