Continuous Delivery of Azure Web Services

See this:

https://azure.microsoft.com/en-us/documentation/articles/cloud-services-dotnet-continuous-delivery/

Adding extra files to your MSDeploy web package with MSBuild

I've recently started getting much more in depth with Azure. I've ported some web apps up into Azure, and now I need WebJobs. I've written the jobs, manually uploaded them into my web apps, tested them out and they work great. Now I need to ensure that the WebJobs get automatically deployed with my Web Application.

As it turns out, web jobs are just a sub folder with some naming conventions underneath the App_Data folder in your web application. Unfortunately, getting those files into that folder as part of the packaging process is a couple extra (non-obvious) steps.

Following this article on ASP.NET, I was able to add in the extra files. It took a lot more Googling than I care to admit to in order to find this article. As it turns out, you really need to pick your search terms well.

Adding files generated at build time to your ClickOnce deployment

So, it used to be that I didn't really like ClickOnce deployment, but it turns out it has a lot of benefits:

• It provides infrastructure that makes it *exceedingly* easy for your average lay-user to upgrade. All they have to do is start the program as normal, and it automatically updates for them (when configured properly)
• It bundles everything up nicely and is easy to install and uninstall (if you're a real person. If you're a script, not so much)

I recently encountered the problem of including files generated at build time (e.g. transformed configuration files) in the ClickOnce deployment package. I found the following that I could include in my ClickOnce project's .csproj MSBuild file:

 <Content Include="Path\To\My.file" Condition=" Exists('Path\To\My.file') ">
<Visible>false</Visible>
 </Content>

 The key part to getting it to work properly is that your build has to do a Build target first, then a Publish target (usually with two separate invocations of MSBuild via a build script, rather than building with a Solution). Fortunately, I was already set up for that, so getting the extra files included was a dream.

Making TFS builds consistent with desktop builds when invoking MSBuild directly on a .*proj file

As it turns out, MSBuild has more than a few quirks when being invoked through TFS compared to being invoked through a command line or from Visual Studio. Some of them are pretty well documented. Others are not, like the fact that in a .*proj file, the OutDir variable is inherited to sub-MSBuild tasks.  There's also quirks because OutputPath is used to determine OutDir, but not in all cases. If you're going to specify OutputPath in the properties when invoking the MSBuild task, you should also explicitly override the OutDir variable as well to ensure consistency, unless you **TRULY** understand the differences between the two and how MSBuild determines OutDir, and you **REALLY** want it to be that way.