Setting the deployed project in a multi-project asp.net core solution in Azure

Posted by lee jones on Nov 16, 2016 in Asp.net, Azure, Cloud

If you deploy a single project asp.net core application to azure everything is about as smooth as it could be. A typical workflow would be to simply create a new web app, set the deployment source (e.g. your git repository) and everything is up and running in a few seconds. If, however, your solution contains multiple projects, how do you specify which project is deployed? Previously this would be done using Azure deployment scripts, but this is a needless effort for such a small task. Just look at the wiki for details on why you may want to avoid this. The preferred way is to specify an Application Setting in the Azure portal. The advantage of this is that you have no deployment code checked in to your source code repository and you can more easily toggle active projects both without deployment and between deployment slots. To do this we need to go to your web app in the portal, click App Settings and create a new App settings key called PROJECT with the path to your project file: However, while this works well with full .net framework applications that use .vbproj and .csproj solutions, at the time of writing asp.net core applications still use the soon-to-be-obsolete .xproj system. If you point your app setting to an xproj, you’ll get an error message in the console. A workaround to this is to update the setting to point to the directory of the solution you want to deploy, relative from the root of your source code repository. In .net core land, this is likely to be along the lines of [Solution name]\src\[project name]\ 1 [Solution name]\src\[project name]\ And you can verify this using the very, very handy console (found under development tools in your web app service list). Open the console and cd ..\repository 1 cd ..\repository and from there traverse your way to your folder containing your xproj. Copy that path (from repository onwards) and use this as the app setting: Redeploy your solution, and you should be up and running with your chosen project. Another benefit… Another nice benefit of this approach is that if you use deployment slots, you can toggle projects per deployment slots, making it exceedingly quick to switch projects just by doing a slot-swap in the...