Wix and Team Build (TFS) integration

At our company, I have struggled for hours to automate the setup package in a Team Build Type in Team Foundation Server.
I found several articles on how to integrate Wix with MSBuild, but none were about using Wix with Team Build. In most of the cases, the msbuild looked like this:

<propertygroup>
<toolpath>C:\Program Files\Wix\</toolpath>
<outputname>MyProjectSetup</outputname>
<outputtype>package</outputtype>
</propertygroup>

<itemgroup>
<compile include="MyProject.wxs">
</compile>

<import project="$(ToolPath)wix.targets">

I added MyProject.wxs (the wix file) in the build type directory and modified TFSBulid.proj and added the above text. The build was not successful of course :) .
After a carefully examining the log files, I noticed that the wix.targets project overrode some tasks and some properties defined in Microsoft.TeamFoundation.Build.targets file. The solution was to change all properties and targets from wix.targets file like this:
from <target name="Compile"> to <target name="WixCompile">, from BuildDependsOn property to WixBuildDependsOn, and so on...
The final step was to call the WixBuild target from AfterDropBuild overriden target.
The final msbuild script looked like this:

<target name="AfterDropBuild">
...
<calltarget targets="WixBuild">
</calltarget>

<propertygroup>
<toolpath>C:\Program Files\Wix\</toolpath>
<outputname>MyProjectSetup</outputname>
<outputtype>package</outputtype>
</propertygroup>

<Itemgroup>
<Wixcompile include="MyProject.wxs">
</ItemGroup>

<import project="$(ToolPath)wix.targets">

Everything works just fine now, and we are able to include in the continuous integration process the deployment and setup packages consruction.

Dynamic ASP.NET web service proxy generation

For many times I have been annoyed by the automatic proxy generation of the ASP.NET web services in Visual Studio. I wanted to work in a more “WCF” style (Windows Communication Foundation), as in using “operation contracts” and “data contracts”. Unfortunatelly, there was no way of doing this in asp.net web services. You had to deal with the duplicated code done by the generator, or you had to manually modify and update the proxy. I considered developing a library for dynamic generation of the web service using only the service contract and the address of the service. With WCF, the asp.net web services are somehow obsolete, but I thought it wouldn’t be so bad to publish my solution, since I havent’ found any way to do dynamic web proxy generation.

Here is how you should use the web service:

1. First, write the service contract (the web service interface, and the data transfer

   objects). Example:

   public interface IWebServiceInterface
   {
   string HelloWorld();
   int GetSum(int a, int b);
   UserDetails GetDetails(string firstName,string lastName,int age);
   }

   
   

2. Then write the service implementation using ASP.NET web services:

   [WebService(Namespace = "http://tempuri.org/")]
   [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
   public class Service : System.Web.Services.WebService, IWebServiceInterface
   {
   #region IWebServiceInterface Members
   
   [WebMethod]
   public string HelloWorld()
   {
   return "Hello World";
   }
   
   [WebMethod]
   public int GetSum(int a, int b)
   {
   return a + b;
   }
   [WebMethod]
   public UserDetails GetDetails(string firstName, string lastName, int age)
   {
   UserDetails ret= new UserDetails(firstName,lastName,age);
   return ret;
   }
   #endregion

3. 
   

Publish the web service, and in order to use it, create a IWebServiceInterface instance:

IWebServiceInterface dynamicService =
DynamicProxy.GetProxy<IWebServiceInterface>("http://localhost/TestService1/Service.asmx");

And there you have it – the dynamic generated asp.net web proxy. You don’t have to worry about duplicated code or manual updates anymore. But pay attention, if you intend to use this code, you shouln’t modify the method or the types namespaces, or other details provided by the attributes, because the library uses only the contract to generate the proxy, and not the information from the WSDL. So the proxy presumes that the web service is in the "http://tempuri.org/" namespace, and all methods are decorated with the [WebMethod] attribute, with no parameters, just as they are generated by the visual studio IDE.

The code generation is done using the System.CodeDom namespace. If you have questions don’t hesitate to write me, or post a comment.

Download source code

Castle project - MicroKernel

In the "Team Work” post I have been talking about an architecture based on contract, in other words – an interface. The presenter for example was using the ILocalDataAccessService and the IOnlineService services.
What happens if the current presenter needs another service? We should change the presenter constructor, and all initialization. We could have the same problem as the one I talked about in the previous post, with the Object Mother – we could have to change the code in a lot of places and maybe hundreds of tests. This is one of the many problems which could appear because of a tight coupled architecture. The dependency using constructor injection isn’t enough sometimes, for example a presenter can use a service only in a specific moment, or it can use a service which isn’t available all the time, so the service shouldn’t necessarily be given as a constructor parameter.
The ideal way is to have an infrastructure, a framework which solves all these problems automatically for us, so we shouldn’t worry about a complex service dependency, or service creation.

The first idea is to have a collection of services, which can be retrieved at any time using their names, and/or interface they implement. These would solve our problem with the service we don’t use all the time, or they could be unavailable at a specific time.

IService service = (IService) Kernel[“My service”];

The second idea is to automate the construction of services, if a service A needs to be constructed and it depends on another service - B, the framework should automatically retrieve the service B from the collection and construct the service A. So the services should be instantiated automatically without having to call explicitly the constructors.
Kernel.AddService(“Service A”, typeof(AService));
Kernel.AddService(“Service B”, typeof(BService));

If the BService class has a constructor with a AService parameter, the framework should automatically call the constructor with the service “A” added in the first step.

Another problem would be the service “style”: is the service a singleton? Or should a different instance be created for every call of Kernel[“My Service”] ? Or maybe create a service for each thread? These details should also be handled by the framework.

So, we shouldn’t be worried when changing the constructor of a service. The infrastructure should have to worry now. We could also use this framework for a plugin architecture: until now, I have worked at a few applications which used plug-ins, and most of the time, a plugin defined in fact a service. I had to do every time my own manager for these plugins. Some plugins were singletons, some would had to be instantiated for every call, but I had to think how to do all this by myself. I didn’t use a framework which could do all the work for me.

Some days ago I have searched for such a framework and I found exactly what I was looking for. It is called the Castle Project – MicroKernel. I started using this framework, and – until now, I am very pleased with the results.

TDD problems - Object Mother

I started working on a new project some time ago, and decided to work in a TDD style as much as I could. The idea was that there were very vague specifications for the project, resulting in a very “agile” project. So what methodology other than XP Programming and TDD should I adopt, I thought.(If you don't know about TDD (Test Driven Development) read about it on wiki.)

I have had some experience with TDD before, but I usually stopped writing tests when I started to develop the user interface. Although I used the MVP design pattern, so I should have been able to test the presenter using a mock as a view, I think this is a very time consuming process, and sometimes maybe not very useful, especially when the presenter logic is not very complex – it takes data from the object and passes it to the view.

The project I was talking about is a monitoring engine. Used to monitor computers, software applications and other stuff… The business was pretty complex, and there was no user interface, so the TDD was almost a must. I started to work in almost in a perfect TDD style, but after some time I found it very difficult to maintain the unit tests.

The problem was that a small change in the business code determined a lot of changes in the unit tests. It was pretty upsetting when seeing 100 compile errors when changing just the number of parameters of a constructor. And very time consuming. At some point, 50% of my work consisted in maintaining the unit tests. Most of my tests were constructing business objects in order to test them. A small change in the constructor or in the manner the business object was constructed determined as I said a lot of errors in the tests. So my idea was to separate the object construction from the unit tests, and make some kind of object factory, but a smart factory, which could create very complex objects with just a function call, or let me customize the object creation.

I found that this method is in fact a pattern, called “Object Mother”:

“Through a handful of simple method calls, this utility provided a complete, valid, and customizable structure of business objects (think of an invoice: its lines, all related charges, remit to, bill to).

Object Mother starts with the factory pattern, by delivering prefabricated test-ready objects via a simple method call. It moves beyond the realm of the factory by

1. Facilitating the customization of created objects,
2. Providing methods to update the objects during the tests, and
3. If necessary, deleting the object from the database at the completion of the test.

Now, when I change the number of parameters in a constructor, I have to change only the object mother not all my 1000 test units, so I consider this method very helpful.