VS2012 Build Server unable to create the workspace due to mapping conflict

I encountered this error message today and went around the houses looking for solutions to my problem:

Exception Message: Unable to create the workspace due to a mapping conflict. You may need to manually delete an old workspace. You can get a list of workspaces on a computer with the command 'tf workspaces /computer

I got the issue by deleting a broken build on our build server and then trying to recreate the build with the same settings in visual studio 2012.

It appears that the Network Service holds on to the mappings of the orginal build under the workspace it created for this.

In order to solve this i had to delete the original workspace from the network service using the following command:

C:\Program Files (x86)\Microsoft Visual Studio 11.0>TF workspace /delete /collec
tion:http://<YOURSERVERNAME>:8080/tfs/defaultcollection <WORKSPACENAME>;"NT AUTHORITY\NETWORK SERVICE"

The workspace name is displayed in the error messgae when you attempt the new build and it fails, it will be something along the lines of 7_1_<YOURSERVERNAME>.

You can also get this information using the TF workspaces command as suggested in the exception message.

Dependency Injection


Dependency injection can be used to satisfy what’s known as the dependency inversion principle.

According to Wikipedia:

In object oriented programming, the dependency inversion principle refers to a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details. 

The principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions. 
B. Abstractions should not depend upon details. Details should depend upon abstractions.

What this means in real terms is that the higher level layers, for example, the business logic layer, should be able to exist independently of the low level layers i.e. presentation. 

If we take an MVC application as an example, we may split our application logic into a separate high level business layer; this then allows our MVC application to deal with the serving of the views at the lower level.

If our high level business layer is aware of our low level presentation layer then it renders our higher level business layer unusable with any other application front end; it’s too closely coupled to the MVC low level presentation layer.

Alternatively, if we make our MVC application reference the high level business layer classes directly, this frees up our high level business layer to be used with other applications, but, leaves the tight coupling on the front end. Our low level presentation layer can’t exist peacefully without our current business logic implementation.

In order to solve this problem we need to create a level of abstraction; we do this by defining interfaces at the higher business logic level that expose the services required.

Our low level presentation layer must now depend upon the high level business logic layer in order to use the interfaces to call out to the application logic. 

In real terms any low level layer adds a reference to the higher level project and utilises the interfaces as a contract to access the exposed services.

Example

In order to demonstrate this concept, we can create a simple MVC4 example application. 
The application consists of:
  • High level business logic layer - ‘DependencyInjection.BusinessLayer’
  • Low level unit testing layer - ‘DependencyInjection.Tests
  • Low level presentation layer - ‘DependencyInjection.WebClient’



We create the business layer first, inside the business layer we generate a simple class to handle the number of cookies that the cookie monster has currently in his possession.

Our cookie manager class looks something like this:



The cookie manager class implements an interface called ICookieManager, in order to create this interface in VS2012, right click on the CookieManager class declaration and select Refactor and then Extract Interface (Alternatively you add and write your own).

This will generate an interface that looks something like this:



All we then need to do on this layer is ensure our interface is public and build the application.

Ok, so now we have our interface and class, we need to add a reference to the business layer from our presentation layer.

Once we've done that; inside the presentation layer we can create a controller that looks something like this:


To do this we bring in a reference to the high level business layer:



 using DependencyInjection.BusinessLayer;

Then create a member variable of type ICookieManager, we create a constructor that takes as a parameter an object of type ICookieManager. 

Our controller is now loosely coupled to our business layer implementation; all the controller class expecting is an interface contract of type ICookieManager as a parameter.

When it comes to writing our unit tests we can use the interface to pass the dependency through to the controller.


Our unit test looks something like this:



You can see the cookie manager type is injected directly into the controller and our unit test passes by returning the correct number of cookies from the controller.

At this stage we can also incorporate a mocking framework and create a mock object that is of type ICookieManager, this will allow us to test the controller in isolation of the service layer and is where dependency injection really comes into its own.

Great, so we’ve called our controller and it’s returned the number of cookies.

So what happens when we run our application?


Well, when we run our application we get the following error:



It states that the application has no parameterless constructor defined for the object. 

Which is correct, we want the application to force the user to inject the dependency into the controller to ensure that we are working strictly from the abstract interface. 

In order for the application to know what object type to pass to the constructor we need to implement a dependency injection (DI) framework to tell the application what type of object to map to the interface.

There are a lot of DI frameworks available online; we chose Ninject.

Ninject

We can download Ninject from the package manager in VS2012 by going to Tools expand Library Package Manager and then click Package Manager Console.
You can use the following Nuget command to install the Ninject application:

Install-Package Ninject.MVC3 -Version 3.0.0.6 

If the application installs correctly we can see a new class in the App_Start folder called NinjectWebCommon.cs.

If we open this class and take a look inside; we can see the associated methods required for the Ninject framework to operate.

In order to add our CookieManager class to the Ninject service register we need to add a reference to our business layer in this class by adding the line of code:



    using DependencyInjection.BusinessLayer;

We then need to register the class we created by adding a binding in to the RegisterServices Class.


Once this binding is added and we run the application, the correct view for the controller should display. 

So that concludes this post on dependency injection; In my next post i'll take a look at how to use a mocking framework to implement your interface on a mock service and test your controller in complete isolation.