Incorporating .NET Core 2.1 into existing .NET Framework/UWP applications

EDIT: As a colleague pointed out, the method below could potentially cause errors at runtime if the .NET Core 2.1 runtime is not installed.

The recently announced .NET Core 2.1 brings some nice new features, but the big draw is the support of Span and it’s performance happy friends.

There’s a slight catch though. .NET Core 2.1 projects can’t be referenced by UWP and .NET Framework projects, so if you have a desktop application in need of a (potential) performance boost to, it’s not as easy as it could be.

UWP Reference Error UWP Reference Error UWP Reference Error
UWP Reference Error

That’s a bummer.

For those who really want to use Span and the other constructs from .NET Core (without having to use the System.Memory nuget package) in their non-Core frameworks, there are some workarounds.

One is to wrap up the .NET Core project as a Nuget package, however the development feedback loop is quite steep. If the project is standalone, this could be a suitable solution, but not so much if the project is just logically separated.

The most suitable solution investigated was to directly reference the .dll (instead of the project itself), although requiring a bit more setup than usual. Referencing the .dll doesn’t build the project it comes from, so if changes aren’t reflected until the project is manually rebuilt.

Directly referencing the generated DLL (requires initial build to generate it) Directly referencing the generated DLL (requires initial build to generate it) Directly referencing the generated DLL (requires initial build to generate it)
Directly referencing the generated DLL (requires initial build to generate it)

This can be alleviated by setting the Core project as a dependency of the non-core project, causing it to be built prior.

Right click Solution –> Properties

Dependent projects are built first Dependent projects are built first Dependent projects are built first
Dependent projects are built first
This leads to the usual F5 experience!

The caveat here is that the configuration doesn’t adapt to the configuration. There is apparently a way of conditionally referencing different dlls to fit configurations, however this might be excessive for most use cases.

Build configuration can specify different project build types Build configuration can specify different project build types Build configuration can specify different project build types
Build configuration can specify different project build types

This is only required as long as the tooling doesn’t support these combinations, however this method should continue to work for the cutting edge versions.

Enjoy the new toys!