Get Specific Version in Visual Studio 2012

Having worked with Microsoft Visual Studio 2012 for some time now, I must say it definitely provides a much better development environment than earlier versions, both in terms of speeds and in usability. There are, however, a few things which I find annoying. One of them is the position of the "Get Specific Version" option from Source Code Explorer.

In Visual Studio 2010, the option was quite obvious … the second option at the top of the right click context menu.

In Visual Studio 2012, this is well hidden inside the Advanced option at the end of the context menu

A few people I know struggled in finding this option, so thought to blog about it.

Visual Studio Designer and TFS Lock

If you have used XAML technologies (Silverlight, WPF, etc.) and Team Foundation Server (TFS), you would be aware of merge issues that might happen with multiple check-outs. The multiple check-out functionality is supported by it's ability to merge code changes. However, due to the nature of XAML code, it is tremendously difficult to get the merging right.

A workable solution is to disable file merging for XAML and XAMLX files. This can be configured through  Team Project Collection settings. If you are using Visual Studio 2012, clicking on the Source Control option shows the following option:

Click on the Add button and add the name and file extension for XAML and disable the option "Enable file merging and multiple check out".

Disabling this option means that TFS locks the file for all other users once it is checked out by anyone. If a user attempts to explicitly check out the a locked file, an error message is shown to the user. However, if the user attempts to do it implicitly by editing a file, the error is shown in the output window.

Now, here is something which I got me burnt today. For text based such as .cs, .xml, etc. the behaviour of Visual Studio 2012 is what I expected i.e. the file is locked for editing and it is very obvious that the files are not checked out. However, if the file is opened on visual studio designer such as Workflow files, Visual Studio still allows you to drag activities on to the designer but the file is not written to. So, keep an eye on the  lock icon .

Visual Studio 2012 Update 1

Update 1 for Visual Studio 2012 is now available. There are a number of bugs fixes and pending features added to this update. The details can be found form the blog post http://blogs.msdn.com/b/somasegar/archive/2012/11/26/visual-studio-2012-update-1-now-available.aspx and the update can be downloaded from here.

Unit Tests using Microsoft Fakes framework in Team Build.

My last post was about Microsoft Fakes Framework. One thing to know about using Microsoft Fakes is that MSTest.exe does not support it. MSTest.exe used to be the executable that Visual Studio 2010 and earlier versions used to run unit tests. It is not the case anymore Visual Studio 2012 uses a command line tool vstest.console.exe. It resides in the %ProgramFiles%\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\ directory of your visual studio installation.

VSTest.console.exe provides most of the features of MSTest.exe  (there are a few alternatives), however, the version that was shipped with the initial release of Visual Studio, did not support publishing test results to TFS. This will change with Visual Studio 2012 Update 1, which is due to be released soon, but if you are a daredevil, you can try the Visual Studio CTP which is available for download now.

Also, if you are still using Team Foundation Server 2010, the default build template using MSTest activity, which uses MSTest.exe behind the scenes. This means that some of the unit tests which are working for you in Visual Studio environment might not work on the Team Build.

I am working on providing an activity in the Community TFS Build extension project to fill up this gap. For now, you can use InvokeProcess activity passing in all the command line parameters.

Microsoft Fakes Framework

If you have done any Test Driven Development than chances are that you have used one or more mocking frameworks. Mocking frameworks are great in that they isolate your code module from the layers underneath thus allowing you to execute your unit tests without elaborate test set up code. Also, they allow replicating different test scenarios. You can set up different responses from same calls to external components for different test scenarios.

With Visual Studio 2012, Microsoft has introduced a new Mocking framework called Fakes. To date, it is only available with the Ultimate edition of visual studio. The framework is comparable to other open source mocking frameworks such as RhinoMocks and Moq but has the following two advantages over others

1. Great Integration with Visual Studio: The integration with Fakes with Visual Studio 2012 is brilliant. To create a "fake" of an assembly, a user needs to just right click on the references and click the option "Add Fake Assembly".

2. Shims: Most mocking framework works by allowing developers to create a "Stub" of an object. Stubs are objects created on the fly, which implements the same interface as the original object. The caller controls the behaviour of the stub by specifying responses for the methods in the interface. Shims are different in that they "inject" code in the original assembly i.e. although the original object will be created but the code executed will the one specified in the shim. This is quite powerful in that it allows developers to specify behaviour of system assemblies, sealed classes and non-virtual methods. E.g. if you are writing some code that need to do something on the 1st day of a year and you are using System.Now, you can "Shim out" this System.Now to return first of January.

When you add a fakes assembly in your test project by right clicking on the reference assembly and clicking the "Add Fakes Assembly" option, visual studio adds the following files

1. A new "Fakes" folder is created with a .fakes files created in it. For example, if you are creating fakes for "System.Configuration", a file called "System.Configuration.fakes" will be created. 

2. A new "FakesAssemblies" folder is created with three files created namely originalAssembly.assemblyversion.Fakes.dll, originalAssembly.assemblyversion.Fakes.xml and originalAssembly.assembly.Fakes.fakesconfig. So, for "System.Configuration" assembly the files generated would be System.Configuration.4.0.0.0.Fakes.dll, System.Configuration.4.0.0.0.Fakes.fakesconfig and System.Configuration.4.0.0.0.fakes.xml.

Visual Studio also adds a reference to the generated assembly in the "FakesAssemblies" folder.

The files in the "Fakes" folder are only generated at the time of adding the fakes assembly. They are added to the solution and should be checked into source control. 

The "FakesAssemblies" folder and all the files in it are generated whenever the project is compiled. This is important because if you are adding fakes for assembly for a changing component, the generation of FakesAssemblies will ensure that all changes are reflected in the generated assembly.

The purpose of this post is not to write details about Fakes and how to use it, but to mention about a "Gotcha" that you might stumble upon while working with it. I spent some time trying to fix that and wanted to write about it so that no one else gets burnt.

The issue was that one of the test projects using fakes was giving a compilation error when built by Team Build and failed with the following error

"Could not resolve this reference. Could not locate the assembly "System.Configuration.4.0.0.0.Fakes". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors."

The error would go away if I added the FakesAssemblies folder to TFS. This is not how it is meant to work. On closer examination, the reason this error happened was because the “Build action” for the .fakes file added to the project was not set correctly. These files should have the build action set to "Fakes". 

It was set to “None” 

and this is the reason why the fakesassemblies were not getting generated in the team build.

IIS Deployment and Windows Server AppFabric services.

I had been getting the following error intermittently while deploying some IIS artifacts on a Windows 2008 server with Windows AppFabric installed on it

FileLoadException: The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020)

Since, all deployments to IIS result in modifications to the applicationHost.config file, it was obvious that the FileLoadException was raised for this file. Using the Unlocker utility, I found that the file was locked by the two AppFabric services i.e. "AppFabric Event Collection Service"  and "AppFabric Workflow Management Service".

The workaround is to stop the two services before you do any deployment on IIS and start them afterwards.

If you are not familiar with applicationHost.config file, this link is a good resource to understand the structure and use of this file.

Here we go again...

It's been more than two years since I posted on this blog. It's been busy couple of years and I have been involved in a few interesting projects using some exciting technologies. I will write about my learnings from last years in due course. Just wanted to write something for now :)