The project needs to be deployed before it can be started…

Have you ever experienced the following error message popping up in Visual Studio, instead of starting the App to debug?

Deployment error message

This situation mostly occurs when starting the UWP part of a Xamarin.Forms project, but is not limited to this scenario. In general, it seems that the problem arises when adding a UWP app project to an already existing solution, setting it as startup project, and running the debugger (which apparently is exactly what Visual Studio does when creating a Xamarin.Forms project from scratch: An empty solution is created, to which a Portable Class Library or Shared Project is added, and finally all the platform-specific projects are created and inserted into the (at that time) already existing solution). The situation can also be reproduced by opening a new Visual Studio window, creating a Portable Class Library project, and adding a UWP app project to the solution.

How to overcome the error message and get the App to start up? The message is quite descriptive: Open Visual Studio’s Configuration Manager by right-clicking the current solution in Solution Manager, and choose Configuration Manager. Here, all projects are listed that are part of the current solution, followed by their default configuration (usually Debug / Release) and target platform. In addition, it is possible to define whether each project should be built and deployed when building the whole solution.

Configuration Manager

It seems that these two check boxes are only automatically checked when creating an UWP project as the only project within a solution. We can obviously check these manually to make the UWP app build and start up. But what’s behind the Configuration Manager window and the settings changed in there?

The Configuration Manager settings obviously apply to the whole solution, so let’s take a look at how the solution is built and stored! In your solution’s root directory, there should be a .sln file. Load this into any text editor – don’t worry, it’s not a binary files but perfectly readable for humans (well, probably not all of them, but it should not be a problem at least for developers)!

The first section of the solution file lists all projects referenced by the solution, e.g.:

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "App1.UWP", "App1\App1.UWP\App1.UWP.csproj", "{9CCEFEF9-259B-46E4-AE57-7865C17EF6E9}"
EndProject

The project name and path attributes should be self-evident. The GUID shown at the beginning of the line depicts the type of project – see List of Visual Studio Project Type GUIDs for an overview. The most interesting part for us is the second GUID per line – this is used to represent each project in the setion of the solution file. Let’s scroll down to the GlobalSection(ProjectConfigurationPlatforms) = postSolution section, and look out for the GUID that represents our UWP project. This section lists all configuration that are activated, for each project. Look out for the lines matching your current configuration (if you just created the solution, these will probably be Debug and Any CPUM: There should be at least one line containing ActiveCfg. We can add two additional lines below, replacing ActiveCfg by Build.0 and Deploy.0 respectively:

{9CCEFEF9-259B-46E4-AE57-7865C17EF6E9}.Ad-Hoc|Any CPU.ActiveCfg = Release|x86
{9CCEFEF9-259B-46E4-AE57-7865C17EF6E9}.Ad-Hoc|Any CPU.Build.0 = Release|x86
{9CCEFEF9-259B-46E4-AE57-7865C17EF6E9}.Ad-Hoc|Any CPU.Deploy.0 = Release|x86

These two lines tell Visual Studio to carry out the build and deploy processes (to be exact, the first such process, as the .0 represents an indexer, but in most cases there will be only one build and deploy action defined anyway).

Save the file, switch back to Visual Studio, choose Reload all when asked what to do with the external changed. In Configuration Manager, the UWP project should now be marked to build and deploy!