This is an example repository on how to target .NET 4.6, .NET 4.7 and UAP 10.0 using a single project.

This project has been written as an example for the blog post about multi-targeting platforms with a single project.

Along the way, this example has been expanded with the following new Cake build scripts:

• Build multi-targeting class libraries (components)
• Build WPF apps
• Build UWP apps
• Build Chocolatey tools
• Build GitHub pages
• Build web apps (Octopus Deploy and Azure Web Apps)
• Build docker images

The scripts are set up in a way that allows a combination of these items as well (e.g. a WPF with an API library) can all be set up. For more information, see the RepositoryTemplate repository.

1. Open powershell with the repository as working directory
2. .\build.ps1 -target package

The scripts are extremely generic. One only has to customize 1 file:

• /build.cake

Below is an example script to package a (multi-targeting) component, wpf and uwp app in a single solution:

//=======================================================
// DEFINE PARAMETERS
//=======================================================

// Define the required parameters
var Parameters = new Dictionary<string, object>();
Parameters["SolutionName"] = "Ghk.MultiTargeting";
Parameters["Company"] = "Geert van Horrik";
Parameters["RepositoryUrl"] = string.Format("https://github.com/GeertvanHorrik/{0}",  GetBuildServerVariable("SolutionName"));
Parameters["StartYear"] = "2018";
Parameters["UseVisualStudioPrerelease"] = "true";

// Note: the rest of the variables should be coming from the build server,
// see `/deployment/cake/*-variables.cake` for customization options
// 
// If required, more variables can be overridden by specifying them via the 
// Parameters dictionary, but the build server variables will always override
// them if defined by the build server. For example, to override the code
// sign wild card, add this to build.cake
//
// Parameters["CodeSignWildcard"] = "Orc.EntityFramework";

//=======================================================
// DEFINE COMPONENTS TO BUILD / PACKAGE
//=======================================================

Components.Add("Ghk.MultiTargeting");
Tools.Add("Ghk.MultiTargeting.Tool");
WpfApps.Add("Ghk.MultiTargeting.Example.Wpf");
UwpApps.Add("Ghk.MultiTargeting.Example.Uwp");
TestProjects.Add("Ghk.Multitargeting.Tests");

// Not included:
// DockerImages.Add("Ghk.MultiTargeting.DockerImage");
// WebApps.Add("Ghk.MultiTargeting.WebApp");
// GitHubPages.Add("Ghk.MultiTargeting.GitHubPages");

//=======================================================
// REQUIRED INITIALIZATION, DO NOT CHANGE
//=======================================================

// Now all variables are defined, include the tasks, that
// script will take care of the rest of the magic

#l "./deployment/cake/tasks.cake"

And if you are not using a build server (seriously, you should be), you could choose to customize /deployment/cake/*-variables.cake as well.

The Cake magic happens in the generic scripts in /deployment/cake/*.cake

Below are a few example targets using exactly the same scripts:

As you can see, there is a pattern:

• Build[SpecificTarget]
• Package[SpecificTarget]

Note that [SpecificTarget] is optional

Compared to the original multi-targeting example, the following changes were made.

To make sure I could still use the defines we invested in (to maximize code-sharing, we use a lot of #if in code shared between WPF and UWP). This project creates the following defines:

• .NET 4.6 => NET; NET46
• .NET 4.7 => NET; NET47
• UAP 10.0 => UAP; NETFX_CORE
• .NET Standard 2.0 => NS; NS20; NETSTANDARD; NETSTANDARD2_0

The project structure adds this line to the project to include the SolutionAssemblyInfo and GlobalSuppressions files which are in the root of the solution.

<Compile Include="..\*.cs" />

To allow sharing of code-behind of a view (for example, for custom controls), we need to to a bit of hacking. We create the view inside each platform specific view directory:

• Platforms\net\Views\MyView.xaml (+ .cs)
• Platforms\uap10.0\Views\MyView.xaml (+ .cs)

After creating the views, one will need to customize the code-behind to add a partial method:

public partial class MyView
{
     public MyView()
     {
         InitializeComponent();
 
         Construct();
     }
 
     partial void Construct();
}

Next, create a partial code-behind class inside the regular views folder that contains the shared code:

• Views\MyView.xaml.cs

This view should contain the following code and allows sharing code-behind but have per-platform xaml files:

public partial class MyView
{
     partial void Construct()
     {
         // TODO: Add shared constructor info here
     }
}

As an example, a dependency property is added in the shared code-behind that shows how to deal with the different platforms in shared code using defines.

• Multi-targeting the world: a single project to rule them all (Oren Novotny - January 4, 2017)