# Tuesday, October 4, 2016

I ran across this error when installing a new Release Agent and it got to the Azure File Copy stage. Many of the solutions on the Internet to this problem point to it being caused by incorrect times on the Agent machine or the target server. However all servers had the correct time and were in the same time zone.

My problem appeared to be caused by my token Endpoint from VSTS connecting me to Azure. When I renewed this endpoint certificate the Azure File Copy task magically worked. The only difference I could see from the previous agent I had, was that my new Agent was a new Virtual Machine compared to the older one which was a Classic Azure Virtual Machine.

I hope this helps someone.

Tags: VSTS

Tuesday, October 4, 2016 5:46:37 PM (GMT Daylight Time, UTC+01:00)  #    Comments [0]

# Friday, July 22, 2016

I started using Microsoft Fakes for some code I was not able to encapsulate and use Interfaces for (my preferred approach) . One of the issues I had was the documentation didn’t appear to be all that good compared to the wealth of information available for RhinoMocks and MOQ especially around Instance methods.

Here is my scenario. I was calling an external class from my code and wanted to test some code that handled an error if the code was called on the second attempt. In Rhino Mocks or MOQ this type of expectation was very easy to code but with Microsoft Fakes the majority of examples appeared to be around static methods.

I knew you could use the AllInstances method for all Instances however I was not clear how I could have an instance do something different when called the next time. My approach was to store the amount of times it was called in a variable and then do something based on that variable count.

Anyway to cut a long story short here is my approach.

    using (ShimsContext.Create())
		int shimCalled =0;
		ShimExternalServiceHttpClientBase.AllInstances.GetTransactions =(x,y,z)
				 return Task.FromResult(new List<TransItem>() {new TransItem() {Id = 99}, new TransItem() {Id = 33}});
			return Task.FromException<List<TransItem>>(new TransException());
		var transcalculator = new TransCalculator();
		var results = transcalculator.CalculateResultsForBatch(1);

This approach works well for me. Basically on the first call I want data to be returned and on the second call I want to raise an error to check that my code can handle this type of error correctly.  I must also point out that this method I am shimming uses async calls hence the Task.FromResult and Task.FromException being used.

I am not entirely sure if the above is the best approach to use however I was unable to find another way I could use an instance method in this way.

Tags: Shims | TDD | Visual Studio

Friday, July 22, 2016 5:09:08 PM (GMT Daylight Time, UTC+01:00)  #    Comments [0]

# Wednesday, November 25, 2015

We’ve been on the preview of “Release” for a while now and have been using it for several deployments. Its a great product when you have figured out how it works and as the documentation improves this should become easier.

Currently we are using Release to publish the same ASP.NET MVC web application to 3 websites with different parameters in each config (replaced with tokenisation) and to drop a packaged version of our web app for download from an external website.

Sounds pretty cool doesn’t it? Well it took a lot of getting around and I am keen to hear back from anyone who may have better ways of handling the configuration file part. Much of what we have done so far has been trial and error mainly between my colleague Richard Erwin and myself.

In this article I will cover deployment to an Azure website. In a later article I will cover how we deployed to an IIS web server hosted on an Azure virtual machine followed by wrapping up software for download from your website. Just as a warning we use a self hosted Release Agent to do our deployments and this example will probably only work with a self hosted Release Agent.

Update note:
For the purposes of this article, I forgot to add that we made use of the Custom VSO-Tasks for Zip, Unzip and Tokenisation which you will need to install before hand.

Creating a parameterised deployment of an ASP.NET MVC application with Release to an Azure website


In the image above you can see the steps involved in Release.

Setting up a vNext Build with parameters

The first step we need to do before we get to Release is to create a Build in VSO that

  • Uses a parameterised xml file with tokens to replace the parameters in your web.config (or other configurations files).
  • Create an MSDeploy zip file as its output

If you have done all of the above and just want to get to the Release bit, scroll down to Setting up Release.

Custom Parameterized XML file with Tokens
As you can see in the image below I have a parameters.xml file in the route of my MVC application if you have not used this type of file before you can find out more about it here. Its a pretty standard part of MSDeploy which is what you are using behind the scenes.


The only difference in our file is that we have replaced the default values with tokens. Tokens are represented with the following syntax __MYTOKEN__ . These tokens will be replaced later by a process in a our Release workflow.  We are basically telling this file to replace the parameters (represented by the match statements) in our web.config and visualisation.config files above by the defaultValue which in this case we have placed our token in for replacement later by Release.

Create an MS Deploy zip file as the output of our build.
In VSO create a new vNext Build using the Visual Studio template


On the “Visual Studio Build” Step select your solution (you will be prompted to locate this in TFS version control (or GIT) when clicking the button with the 3 dots next to the option.


In your MSBuild arguments you will need to do the following

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true

The DeployOnBuild and WebPublishMethod arguments tell the build to create the MSDeploy packages for us. This is simply a zip file that MSDeploy can use to deploy to an IIS box or an Azure website.

Further down in Publish Build Artifacts we tell the build what we want as an output from this build. In our case all we want is the MSDeploy zip file. In this case we represent this by asking the publish step to find a zip file for us in the build output using the following syntax “**\*.zip” (see image below)


Setting up Release
For the purposes of this article I am doing an Azure Web deployment first but will follow up with another article that will go through IIS deployments.

You will need to install the  Custom VSO-Tasks for Zip, Unzip and Tokenisation before continuing.

A note about Release Agents
This article makes the assumption that you have at least some familiarity with Release. In this section we are using our own release agent installed on a virtual machine. A release agent is basically the same concept as how a build in VSO can have its own agent that you can host yourself instead of using the hosted build agent. If you do not have your own Release Agent setup there is a guide here on how to do so. You basically run a PowerShell script on a machine you wish to act as your release agent. If you are experimenting you can even use your own desktop or laptop as a release agent. Release Agents will need Internet access and be located where they can see the target environment you are deploying to.

Go into your VSO project and select the Release tab. Create a new Release in this case we are doing an Azure Website Deployment.


The default release you will see only has two tasks inside it. For the purposes of our setup we had no need for the Visual Studio Test which can be deleted.


In our release we added the following tasks (see the image below) which I will go into more detail below.

Its a good idea now to set your environment to use your hosted Release Agent if you haven’t done so already. You can do so by clicking on the 3 dots next to the environment name and selecting Agent Options and setting the Default queue to your Release Agent.


To select the contents of the vNext build you created previously select the Artifacts tab and select “Link an artifact source” button. Basically you are releasing the contents of a build.


Unzip Task
Select the Environments tab again and Add a task this task will be under utilities and be called UnZip. You can drag this task to the top of the list by holding down on it with your mouse.

In your Unzip Task you can select the zip file that is provided by your build output (this is the step we did previously in creating a build above). The output of our build is a zip file used by MS Deploy. We are just telling the Unzip task to unzip this. Note you will have to run at least one successful build to see the contents of your build using the navigation used by the 3 dots button next to the option.


The target folder is a folder on our build agent. The above path comes from clicking on the 3 dots next to the target folder. In this case I have only gone one folder deep and placed my own folder name in there called “VSO” which the zip task will create and unzip the contents of the package to.

Tokenisation: Transform file
Add a tokenisation task in the same way you added an Unzip task above.

Remember the previous step we did above “Custom Parameterized XML file with Tokens”? All we are doing is telling our Tokenisation task to find that parameters.xml file  we created in that task in the folder that was created in Unzip task above. This task will replace the tokens in our parameters.xml file with our custom variables (you can read more about where to set these further down).


Batch Script
This is probably the least elegant part of my solution and I am open to any suggestions people might have to improving it. In order to make the MS Deploy package work again we need to zip it up, unfortunately we can’t just use the Zip task that is available to us as MS Deploy will for some reason ignore any zip file that was not created with MS Deploy! To get around this we had to install MS Deploy on the build agent box (this is why I am using our own build agent).


This batch script task basically tells Release to execute the batch file located on my build agent server with three parameters. The script is listed below and lives in a path on the build agent indicated in the image above.

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe"  -verb:sync -source:archiveDir=%1 -dest:package=%2 -declareParam:name="IIS Web Application Name",defaultValue=%3,tags="IisApp" ^
-declareParam:name="IIS Web Application Name",type="ProviderPath",scope="IisApp",match="^.*PackageTmp$" ^
-declareParam:name="IIS Web Application Name",type="ProviderPath",scope="setAcl",match="^.*PackageTmp$"

All the batch file does is takes the 3 arguments which are

  • The working folder we unzipped our website to and ran the tokenisation task on
  • Where we would like to place our new MSDeploy package and call it, in this case its VBX.zip which we are placing in the working directory of our agent. In the example above ours is: $(Agent.ReleaseDirectory)\VisualisationBoard2015\VSO.zip
  • The name of our IIS website.

It uses these to recreate the MSDeploy package for us again.

Note arguments are separated by a space and each argument is placed inside quotes.

Azure Web App Deployment Task
Finally we get to the last task. If all went well in the batch file task above, we should be able to tell this task to use the MS Deploy package we just created in the previous step. In this case it is



Note if you are unsure how to setup your Azure subscription and website on the Azure deployment task you can find out how to do so here . If the Azure web App does not exist Release will create it for you.

Where do I put my parameters for tokenization?
While still in your Release click on the Configuration tab. This is where you enter the tokens you wish to replace in your parameters.xml file for example the parameter __AUTHENTICATION__ is simply represented by the name AUTHENTICATION without the underscores. The tokenisation task will look for these here.


The tokenisation task will also check your environment specific variables which can be found on each configured environment.


The beauty of this is that you can have a different set of variables per environment.

Once you are done you can now kick off a Release and see if it works!

Trouble Shooting
We have found when trouble shooting release. It helps to have access to the Release Agent machine you are using so you can see what is happening in its working directory. Usually an issue could be down to mistyping a name or getting a directory path wrong.

I am keen to hear back from anyone who has a better way of using release for tokenized website deployments.

Tags: TFS

Wednesday, November 25, 2015 2:31:53 PM (GMT Standard Time, UTC+00:00)  #    Comments [4]

# Monday, July 20, 2015

Recently I have been doing a lot of coding, and we’ve been working on some exciting things at RippleRock from Lean Coffee Table, TFS Rippler and some advanced HTML 5 charting tools. Our working atmosphere at RippleRock is pretty relaxed with a good work-life balance. As our consultants are usually spread through out the UK (and even some parts of Europe and occasionally India), we make a lot of use of technology to stay in touch with each other. We are all very driven and passionate people about what we do which also makes working remotely from each other (when we need to) much easier to do.

Morning Ritual
The morning ritual is very much the same as a co-located team, we have an early morning stand-up. I personally feel that the day hasn’t started properly unless we have one of these.  One of us will open our task board and display it to the rest of the team and we will talk about what we have done and what we will be working on next. 

Remote Pair Coding
We stay in touch using Skype for Business, Skype or Google Hangouts depending on what works best for our situation. Skype For Business is our go to app for remote pair coding. It enables either party to take control when working together. The developer who has control of the keyboard listens to the observer who directs. We can switch control by giving the observer control using Skype for Businesses “Give Control” functionality. We don’t always Pair Code when working remotely as it can be quite taxing being on a remote call for several hours, however as a team we can spot bits of work we believe will be better worked on while pair coding and when we do this, we end up with some very good results.

Feedback Loops
Because constant feedback is so important we focus on small chunks of work that are regularly committed to source control, run in our CI build and deployed to a server. This ensures we have constant feedback for our morning stand-up's. This also encourages us to try things out quickly if we are unsure on what is the best approach, because our feedback loops are so short we can afford to fail quickly and this way choose the best solution that works.

Code Reviews and refactoring
This pretty much works in the same way as co-located teams. Sometimes we pair when going over code if we need to figure out what was the idea behind some decisions. Other times code is changed and shelved as a suggestion to the developer who is having code reviewed and they can look over the suggested changes, compare and incorporate them to ensure they understand them.

Tools are not a replacement for process they only help facilitate the process especially for when we are are working remotely. The key tools we have found are as follows

  • A shared remotely viewable board of work. Any kind of web based board be it TFS, Jira or LeanKit will help here to make work visible.
  • Source Control basically goes without saying how important this is.
  • Remote conferencing tools like Skype, Skype For Business or Google Hangout are important. Those that enable remote desktop control are even better.
  • CI Builds kicked off after check-ins provide a fast feedback loop.
  • Wiki or central document area. We find a Wiki for quickly jotting up helpful documentation essential and it encourages use because of how easy it is to use.

Tags: Agile | Remote Working

Monday, July 20, 2015 1:35:47 PM (GMT Daylight Time, UTC+01:00)  #    Comments [0]

# Wednesday, June 24, 2015

I wrote this article more as a reminder to myself on the process I need to go through to make a web application written in ASP.NET (MVC) that uses the TFS API to actually work. I have done this several times now but keep on forgetting some of the key information. Some of the errors you may get if you haven’t set this up correctly are.

Error HRESULT E_FAIL has been returned from a call to a COM component.


There are two things you need to set correctly and they are your Web.Config and IIS.

The first port of call is to setup the following in your web.config. Basically we are saying we want to use Windows authentication in our app and to turn on impersonation.

1 <system.web> 2 <authentication mode="Windows" /> 3 <identity impersonate="true" /> 4 5 <authorization> 6 <deny users="?" /> 7 </authorization> 8 </system.web> 9 . 10 . 11 . 12 <system.webServer> 13 <validation validateIntegratedModeConfiguration="false"/> 14 . 15 . 16 </system.webServer> 17

IIS Settings
The rest of the settings are dealt with in IIS.

In IIS click on your website and then select Authentication from the Features menu. Set these to the following (as per the image). Basically ASP.NET Impersonation, Windows Authentication are set to enabled. Anonymous should be set to Disabled.


App Pool Settings
Go to advanced settings on your App Pool, one thing you may need to set here is “Enable 32-Bit Applications” if you are working with the TFS Client API (this can be found under (General))

Scroll down to Process Model and find an identity section. This for a newly created app is usually set under the App Pool Identity account. This needs to be set to either a domain account that has access on the box or I have seen the local system and local service accounts also work here. However I believe this is only the case if you have set TFS to run under one of these as a service. In my case I have used an AD account that has access to the box. The next important step here is to set “Load User Profile” to true. Setting this appears to be critical especially when working with the WorkItem Tracking Client. I believe it needs to create a cache on disk when it does this. Not setting the Load User Profile may prevent it from doing this.


Tags: TFS

Wednesday, June 24, 2015 1:04:47 PM (GMT Daylight Time, UTC+01:00)  #    Comments [0]

# Thursday, May 21, 2015

This post is more for my own reference as I spent a bit of time trying to figure this one out. For a long time now you have been able to choose your own Team field in TFS and let TFS know this using the following method https://msdn.microsoft.com/en-us/library/vstudio/dn144940.aspx . I was recently working on an application where I needed to know the Team Fields name programmatically.  Below is the code I used to do this.

For the code below to work you will need to include

  • Microsoft.TeamFoundation.Client
  • Microsoft.TeamFoundation.Framework.Client;
  • Microsoft.TeamFoundation.Framework.Common;

In the example below we pass in the Guid of the TFS Collection we are after followed by the TFS project name. We then use the Process Configuration Service to get us the details about the project

1 var _tfsTeamProjectCollection = new TfsTeamProjectCollection(new Uri(_tfsUrl), 2 new System.Net.NetworkCredential(_tfsUserName, _tfsPassword)); 3 4 _tfsTeamProjectCollection.EnsureAuthenticated(); 5 6 var teamProjectCollection = 7 _tfsTeamProjectCollection.ConfigurationServer.GetTeamProjectCollection(tfsCollectionGuid); 8 9 var settings = teamProjectCollection.GetService<ProjectProcessConfigurationService>(); 10 11 ICommonStructureService4 cssService = teamProjectCollection.GetService<ICommonStructureService4>(); 12 13 var projectInfo = cssService.GetProjectFromName(projectName); 14 15 var proc = settings.GetProcessConfiguration(projectInfo.Uri); 16 17 var sets = proc.TypeFields; 18 19 string teamField = null; 20 21 foreach (var typeField in sets) 22 { 23 if (typeField.Type == FieldTypeEnum.Team) 24 { 25 teamField = typeField.Name; 26 } 27 }

I am sure the above code example can be tidied up and adapted a bit more.

Tags: TFS

Thursday, May 21, 2015 9:19:40 AM (GMT Daylight Time, UTC+01:00)  #    Comments [0]

# Thursday, April 30, 2015

One of the most exciting things I took away from Microsoft's Build 2015 event on day 1 apart from the fact they were embracing all platforms this time was how they proved that by releasing their first code editor that works for all environments Mac OS X, Linux and Windows. Visual Studio Code was a bit of wow moment for me it kind of said “They really mean it”


Visual Studio Code seems to have quite a light footprint. The install was pretty quick and as soon as the app launched I realised it looked strikingly familiar to Microsoft's online code editor I have been using for an Azure website called Monaco (below)


Visual Studio Code (below)


I would imagine that this is intentional so users have an online and offline version of the editor. To get started with development Microsoft have some tutorials setup specifically for Visual Studio Code. You can get started with a ASP.NET 5 app in Visual Studio Code using the tutorial found here. As Visual Studio Code is so light weight all scaffolding for your projects is done from the command line.

To get started with the tutorial you will need to install:

If you haven’t installed VS 2015 before you will need to install DNVM (.NET Version Manager) which you will later use to install dnx (this is covered in the tutorial)

NodeJS will also need to be installed which will install npm (the package manager for Node.JS) if you haven’t used npm before this, its not that clear from the tutorial.

After you have followed the tutorial you should have a scaffolded project you can view in Visual Studio Code. If you don’t want to go through the above tutorial you can always create the project in VS 2015 and then view it in Visual Studio Code.

What I like about this and saw quite a lot of this mentioned is how Microsoft is embracing other initiatives instead of reinventing the wheel and making everything the “Microsoft way” as they have previously done in the past.




Editing code in Visual Studio Code is a breeze and I quite like how light weight it is and if you have been using Monaco it shouldn’t seem too different to you especially the integrated Git access. You can also launch kestrel (the web server) from the command line. However while I was able to get most things working with Visual Studio Code I was unable to get Debugging working for my MVC application. The documentation does state that debugging is not yet supported in Mac OS X and Linux although I was using a Windows machine at the time.


Thursday, April 30, 2015 12:04:03 PM (GMT Daylight Time, UTC+01:00)  #    Comments [0]

# Monday, January 26, 2015

Checkout this excellent article by Mark Rendle on running ASP.NET 5 with Linux and Docker.



Monday, January 26, 2015 10:44:30 AM (GMT Standard Time, UTC+00:00)  #    Comments [0]

# Thursday, January 22, 2015

If you have been keeping up to date with Visual Studio 2015 news. You may have noticed that Microsoft has started adding touch support to Visual Studio 2015. I tried it out on my iPad yesterday and it seems to work quite nicely. How did I use Visual Studio 2015 on my iPad you may ask? Just install Microsoft's Free RDP client for iPad and connected to an Azure VM with VS 2015 installed. It works quite nicely and supports gestures such as pinching to zoom and selecting text with your finger. You can also use the scroll bar to scroll down with your finger.


I would imagine that this would even work on an Android tablet (which now has support for a mouse plugged in) which Microsoft have also released an RDP client for. Or better yet a Windows tablet where you can use VS2015 on the device itself instead of through remote desktop.


Tags: VS2015

Thursday, January 22, 2015 3:12:05 PM (GMT Standard Time, UTC+00:00)  #    Comments [0]

# Tuesday, January 20, 2015

This was one that passed me by over the festive period. If you use the online version of TFS, you can now edit code inside the repository from the web interface and add new files to the repository completely from the web interface.


The above functionality does not appear to be included in Update 4 of the standalone version of TFS.

Tags: TFS | TFS Tools

Tuesday, January 20, 2015 6:25:21 PM (GMT Standard Time, UTC+00:00)  #    Comments [0]