Microsoft Azure and Visual Studio Online Server Builds – Tips & Tricks

April 22 2014

I’m all about deploying web sites and cloud services via server builds. Say goodbye to deployments from a developer’s box that can’t be reproduced on another box. Say goodbye to deploying code that isn’t checked in. Say goodbye to deployments that aren’t fully tested.  It is indeed super cool.

So how to get it set up? There are some good tutorials out there, but it can get a little tricky. Here’s how I did it.

First, make sure that you’ve linked your Azure account to your Visual Studio Online repository as explained in Step 3 here: http://azure.microsoft.com/en-us/documentation/articles/cloud-services-continuous-delivery-use-vso/

Then, if you open VS from the Azure website, it will generate a build template for you that is the name of your Azure deployment with an _CD at the end. You’ll have to tweak some things to get it happy though.

First, go the Build section of Team Explorer window:

0

Then, right click on the Build definition file and click Edit Build Definition.

There’s a bunch of things you will need to change.

In the general tab, make sure you enable the build definition. By default it is disabled:

11

In the source settings tab, make sure it is pointing to the right repository:

1

In the Trigger tab, you may want to tweak when the deployments happen:

111

And, in the Process tab, make sure you point the Project it to the right .sln to build as well as the Configuration you want aka Release | Any CPU.

And, in the deployment settings, make sure that the the Path To Deployment Settings points to your .pubxml file and the Windows Azure Deployment Environment points to the name of the Cloud Service in Windows Azure. 

4

With that all set, you can now build and deploy using server builds!

DebuggerNonUserCodeAttribute Saves The Day

July 14 2011

Sometimes Visual Studio is too smart. Hit a situation yesterday where I has a solution with an .exe and a .dll. In the .dll, there's a method called by the .exe that throws an exception.  I needed to test the logic of how the .exe handled that exception. But, while debugging, the project would always break on the throw in the .dll and I couldn't ever get it to continue on to test my logic in the .exe. 

Finally, I got it to bypass the class in the .dll by attibuting the class dll with the DebuggerNonUserCodeAttribute.  Walla! Now I could check the logic in the .exe when the exception was thrown.