Is there a way to share code between UWP applications and WPF applications?

Question

To be clear, I follow the MVVM pattern, and I want to structure my project so that I can share my model code between a UWP application and a standard WPF application. The code I want to use does not have an interface. I don’t like the idea of ​​finding new tools to replace the ones that I have been using for many years that deal with certain tasks, such as logging, connecting to a document-oriented database, etc.

I tried to start writing a UWP wrapper around some code that I already have, and directly refer to the model project. Visual Studio refused to allow this, showing me an error message that says: “Unable to add a link to the project“ ACK.Model. ”The same thing happened when I tried to put the model in a universal library and reference it from a WPF application. I I don’t want to share WPF code, only a model layer that does not have a link to user interface libraries.

This is a scary proposition because it means that if I want to do something substantial, I must choose to either switch to 100% in UWP or stay at 100% WPF. NewtonSoft.JSON may have universal distribution (ASP.NET MVC), but what about ElasticSearch.NET and other tools needed to create important applications?

---

I found where the project type "Portable Class Library" was hiding. PCL will allow me to share my code in WPF and Universal applications, as this was one of the options. This solves the simple case of part of the model of my code, but I (still) cannot use some of the libraries that I want. I still need a large number of libraries that do not have PCL.

Answer 1

About a year later, with the advent of Visual Studio 2017, there is a more complete solution. If you are targeting your libraries to .Net Standard, then the library is compatible with .Net Core applications and the monolithic .Net target application. Support for standard .Net libraries and APIs is pretty complete, as is support for modern C # language features.

Now a general tip:

• .Net target standard for all libraries
• Set up the right platform for your real application. (UWP or WPF).

NOTE. If your library needs to interact with C libraries or applications, you need to take extra care to ensure that you have downloaded the correct version.

---

There seems to be a solution, but it should be made by the entire tool chain that you want to use. When Microsoft introduced the Windows Store apps on Windows 8, they also introduced the portable class library (PCL). The purpose of PCL is to exchange codes between different parts of your application.

When creating a PCL in Visual Studio 2015, you can specify the types of APIs from which you want to access:

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

This, of course, limits the available APIs, but most of them you want to use if it is not related to the user interface. There are other limitations:

• Your project can only be edited in Visual Studio 2015 or higher.
• You do not have access to special directories from an environment variable (ie, the “User Documents” folder, etc.).
• You cannot reference a library intended only for one of your target platforms (e.g. libgit2sharp, etc.).
• Unable to view the API for this subset - MSDN needs to go on a stick. MSDN has updated most of the API documentation, but it’s still hard to understand what is relevant to your PCL

However, you can link any library designed for one target platform to your PCL. It is not perfect, but it is better than nothing.

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

This scheme makes you think about how you want to integrate better. The .Net Core 5 kernel seems to be stable, but its support is in its infancy. In the current generation of Universal Apps, VS 2015 version 1 uses .Net Core 5 directly.

Nuget has several features that are not currently supported, although work is ongoing:

• Extensions MS Build (major changes in the structure of MSBuild and project.json)
• Install / uninstall scripts (associated with uninstalling the installation concept)
• Content (related to install / uninstall, but work is being done)
• Content conversions (associated with a lack of install / uninstall)

I would like a more complete answer. But this is how much I got when I discovered PCL and how it developed for the current infrastructure.

---

I am creating a game development toolkit that includes version control right away. I want to be able to deploy the game as a Windows 10 application or as a standard WPF application, but because of the libraries I use to integrate version control, I need to create an editor as a standard WPF application. I had to be a little creative in creating shared code and importing the right libraries.

Firstly, my project hierarchy:

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

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

• After adding a link to the NewtonSoft.JSON package, I had to change the target structure in the packages.config file:

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

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

While this is definitely not a panacea, it is also not a dead end. I am sure there are more errors, but this will at least help with some problems.

Answer 2

The .NET standard library can be used to share the Model-View-ViewModel architecture between a WPF project and a UWP project.

https://www.syncfusion.com/ebooks/xamarin-forms-succinctly/sharing-code-among-platforms https://devblogs.microsoft.com/dotnet/announcing-uwp-support-for-net-standard-2 -0 /