Is there any way to share code between UWP apps and WPF apps?

About a year later, with the advent of Visual Studio 2017 there is a more complete solution. If you target your libraries to .Net Standard then the library is compatible with both .Net Core apps and the monolithic .Net targeted app. The support for standard .Net libraries and APIs is fairly complete, as is the support for modern C# language features.

The general advice now is this:

• Target .Net Standard for all libraries
• Target the appropriate platform for your actual application. (UWP or WPF).

NOTE: if your library has to interact with C libraries or applications, you have to take extra care to make sure you load the correct version.

---

It appears that there is a solution, but it has to be adopted by the whole tool chain you want to use. When Microsoft introduced Windows Store apps in Windows 8, they also introduced a Portable Class Library (PCL). The purpose of the PCL is to share code between different parts of your application.

When you create a PCL in Visual Studio 2015, you can specify the types of APIs you want it to be accessible from:

• Universal Apps
• Mono
• .Net Core 5
• .Net 4.6

This of course, limits the APIs available to you but most of the ones you want to use are OK as long as it's not UI related. There are other limitations as well:

• Your project can only be edited in Visual Studio 2015 or greater
• You don't have access to special directories from the Environment variable (i.e. user Documents directory, etc.)
• You can't link to a library designed for only one of your target platforms (i.e. libgit2sharp, etc.)
• There's no way to browse the API for this subset--MSDN needs to get on the stick. MSDN has updated much of the API documentation, but it's still difficult to figure out what applies to your PCL

However, you can link any library designed for a single target platform to your PCL. It's not ideal, but it's better than nothing.

The ASP.NET MVC stack has been ported to using PCLs, so you can use NewtonSoft.JSON directly as well as any other of those libraries used by that application. However, there are several libraries that have not been ported.

This arrangement forces you to think about how you want to integrate better. The .Net Core 5 seems to be stable, but support is in it's infancy. The current generation of Universal Apps as of VS 2015 update 1 uses .Net Core 5 directly.

There are several features from Nuget that are not currently supported even though work is under way:

• MS Build extensions (major changes to MSBuild and the project.json structure)
• Install/uninstall scripts (related to the removal of the concept of install)
• Content (related to install/uninstall, but work is in progress on this)
• Content transforms (related to lack of install/uninstall)

I wish I had a more complete answer. But this is as far as I got once I discovered the PCL and how it evolved for the current infrastructure.

---

I'm in the process of creating a game creation toolkit that incorporates version control right off the bat. I want to be able to deploy a game as a Windows 10 app, or as a standard WPF app, but due to the libraries I'm using to integrate version control I need to create the editor as a standard WPF app. I had to be a bit creative in building the shared code and importing the correct libraries.

First, my project hierarchy:

• Project.Model (Portable Class Library)
• Project.Model.Versioning (standard C# library)
• Mvvm.Toolkit (Portable Class Library)
• Editor (Standard WPF application)

I want the core PCL to be able to load a project and deserialize the JSON encoded objects. The PCL did have access to System.IO, but surprisingly it is not the same as the one defined in the standard C# library. Here's how I had to fix things:

• After adding the package reference to NewtonSoft.JSON, I had to change the target framework in the packages.config file:

  <package id="Newtonsoft.Json" version="8.0.2" targetFramework="portable-net452+win81" />

• All projects dependent on my Project.Model class had to install the `system.io.filesystem' package from nuget so that the System.IO.FileInfo etc. objects were the same.

While this is definitely not a panacea, it's also not a dead end. I'm sure there are more gotchas, but this will at least help with some of the problems.