Build a BizTalk 2009 solution with MSBuild 4.0

I’ve been working on a MSBuild 4.0 script to build our entire product tree. The product tree contains multiple solutions in .NET 3.5, Silverlight 3.0, .NET 4.0 and BizTalk 2009. Most of it wasn’t that hard, the real exception was to let MSBuild build the BizTalk 2009 solutions.

When you build a BizTalk 2009 solution with MSBuild 4.0 you’ll probably get all sorts of messages telling you that MSBuild found 2 versions of System.XML, System.Diagnostics. One version is the correct .NET 2.0 version and the other is the .NET 4.0 version. Why MSBuild doesn’t understand that a .NET 3.5 solution won’t reference a .NET 4.0 assembly is beyond me. The worst part is: There is no way to tell MSBuild which specific assembly you want to reference.

There is a solution only you’ll need to edit your BizTalk project. In the Program Files\MSBuild\Microsoft\BizTalk directory there are two MSBuild target files (BizTalkC.targets and BizTalkCommon.targets). The BizTalk.Common.targets file contains a task AddHiddenReferences. This task will avoid the BizTalk task adding the 4.0 references on hosts with both .NET 3.5 and .NET 4.0 installed.

If you unload your *.btproj files that have a reference to Microsoft.XLANGs.BaseTypes and open it with the XML Editor. Edit your btproj files so they will look something like this:

<!-- other *.btsproj file stuff -->
  <Reference Include="Microsoft.XLANGs.BaseTypes">
   <Name>Microsoft.XLANGs.BaseTypes</Name>
  </Reference>
  <Reference Include="Microsoft.BizTalk.Interop.Agent" />
  <Reference Include="Microsoft.BizTalk.Pipeline" />
  <Reference Include="Microsoft.BizTalk.Messaging" />
  <Reference Include="Microsoft.XLANGS.BizTalk.ProcessInterface" />
  <Reference Include="Microsoft.RuleEngine" />
  <Reference Include="Microsoft.XLANGs.RuntimeTypes" />
  <Reference Include="Microsoft.XLANGs.Engine" />
  <Reference Include="Microsoft.XLANGs.BizTalk.Engine" />
 </ItemGroup>
 <!-- other *.btsproj file stuff -->
 
 <!-- AddHiddenReferences will avoid adding the .NET 4.0 references -->
 <Target Name="AddHiddenReferences" />
</Project>

Reload your project file and build the solution. You will notice that you will have to add a reference to System.Web.Services. After this your solution will build and this solution will also build in MSBuild 4.0.

Difference in MSBuild and Visual Studio Build?

I'm working on a MSBuild script that will retrieve all the sources from TFS and build all the Solutions. To my surprise one of my MSBuild scripts raised errors on a solution that was building fine in Visual Studio. In MSBuild I got the following error: "The type or namespace name "name" does not exist in the namespace "namespace". (Are you missing an assembly reference?)".

After a long hard search I found a stray projectreference in a project file (*.csproj). Usually all the References and Projectreferences are packed together in one ItemGroup, but in this specific project file there was one ProjectReference in a seperate ItemGroup at the end of the file. This was exactly the project that contained the namespace "name". I copied the ProjectReference to the ItemGroup containing all the other References and deleted the stray ItemGroup. This fixed the MSBuild errors.

UnitTests and Code Coverage in TFS Build 2008

The last couple of days I've been working on getting code coverage results from unittests in automated TFS builds. Getting the code coverage results in Visual Studio 2008 is very straightforward:

• Double click on the LocalTestRun.testrunconfig
• Go to "Code Coverage"
• Select the artifacts to instrument (dll's)
• Enter the path to the resigning key file
• Click "Apply" and "Close"

Everything is now set up to run the UnitTests with the instrumentation for code coverage.After you run your UnitTests, left click on a TestResult and open the Code Coverage Results.

Getting the Code Coverage Results in the Automated TFS Build is a bit tricky.
Open the TFSBuild file and add the following line in the PropertyGroup node:  "<RunTest>true</RunTest>"

In the ItemGroup for UnitTesting add the following lines (if you have multiple unittest projects in your Build, add one for each unittest project)

<MetaDataFile Include="$(FolderPath)/TestListEditor.vsmdi">
  <TestList>NameOfTestListToRun</TestList>
  <TestRunConfig>$(FolderPath)/LocalTestRun.testrunconfig</TestRunConfig>
</MetaDataFile>

After you run your build you should see that there are now UnitTest Results and Code Coverage Results in your Build Summary.

Unfortunately this wasn't the case in my project. I got a partially succeeded build, the building itself  succeeded and all my unittest passed, but still I got a partially succeeded build. I noticed that the buildlog contained a lot of the following warnings: "Warning VSP2013: Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this." After some google searches I found this.
The article basically says that the buildserver makes 64 bit dll's and it can't place the instrumentation code for Code Coverage in these dll's because the Code Coverage runs as a 32 bit proces. Microsoft doesn't plan to fix this in the current release, but keep an eye out for new versions. After some more searching I found some other fixes for this problem, you can change the BuildConfiguration to always build Debug|x86 or you can do some Registry hacks on the buildserver. I didn't like any of these solutions so I started to look for different options.

The best option I could find was the following:
In the LocalTestRun.testrunconfig under Code Coverage there's an option to "Instrument assemblies in place" if you unselect this option the Code Coverage instrumention will be placed in a copy of the dll and not in the same dll. Unselect this option and restart the build.
You will now see that the build will complete succesfully!

Silverlight 3 MVVM Project Part I (updated Architecture)

I know things in IT change fast, but I didn’t know things could change this fast. As soon as I posted my previous blog on the Silverlight 3 MVVM Architecture, it was already outdated. So here is the update.

We decided that because we use bindings to get a reference to the commands, the commands are actually a part of the viewmodel. So the updated architecture looks like this:

A View implements an interface, this is a change on the previous model. For a composite application I don’t want to implement a hard dependency on a specific kind of view.

For example: Let’s say I have a module that allows me to search for a person (SearchPersonModule) and I have another module that allows me to search for cars (SearchCarModule). If I want to use these modules on PersonView and CarView, I would have to specify which module I want to load (hard dependency). This means I’m using my modules as UserControls. This can be a good idea, but it defies the purpose. I’m trying to take it a step further. The SearchPersonModule and SearchCarModule both implement the same interface (Let’s call that ISearchModule). In the PersonView and CarView I now only have to specify that I want a module that implements ISearchModule and leave it up to the Application or IoC container to give me an instantiated version of the right module. (I’ll describe how this is done in the next part of this blog)

A View only has one ViewModel, everything a View needs to know is in that ViewModel (or the ViewEntities). A View can contain other Views and those Views will have their own ViewModel. The ViewModel also creates the Commands for the View, I explained how we use Commands my previous post. The ViewModel is also responsible for any view-specific functions like calculating a total sum or counting the number of persons in a search result.

A ViewModel can have zero or more ViewEntities, ViewEntities are like Data Transfer Objects, they just carry the data that needs to be presented in the View.

The Model is the place where we define the information need for the module. Let’s say I need a country list, the module will request an instance of the ICountryRepository and ask for the Country list. I don’t care what is giving me the the Country list, I just want it. The implementation of the CountryRepository is not my concern. I just know that ICountryRepository has a function List<CountryDataContract> GetAllCountries(). In the model I will map the CountryDataContract to my CountryViewEntity and expose that CountryViewEntityList as a property on the model.

The IService stands for all the service interfaces I have within my application or framework (with service interface I do not mean a web service interface). For the EventManager I have an IEventManager interface and for the PersonRepository I have an IPersonRepository interface.

All the communication to and from the module will be facilitated by the Services. All the communication within the module will be done by the commands.

The next part of this blog will describe the implementation of this architecture.

Silverlight 3 MVVM Project Part I (Architecture)

The last two weeks I got the opportunity to make a proof of concept for a Silverlight 3 application. The best part was: there’s only one requirement! It had to use the MVVM pattern! If you’re not familiar with the MVVM pattern, then check out this wikipedia article, there you’ll find a brief explanation and some more in-depth references.

First I want to start with a “thank you” note to Marc Jacobi for the architectural guidance :). He was always there to keep that workload coming! (or change the color of that square :D)

Marc and I (mostly Marc) started on the architecture of this Proof of Concept. The end result looked something like this:

Like any MVVM application there are still the basic Model-View-ViewModel classes. I won’t explain them here. The module should be a stand alone module. All the data needed (this includes incoming / outgoing information, incoming / outgoing events) should come from a service. The module (Model, CommandActions, etc) will only request interfaces of services, this is where an IoC container is needed.

We extended the ViewModel and Model with the ViewEntity, it’s only purpose is to make the ViewModel a little bit more manageable.

Within the module we only use commands. Silverlight usually uses events like button click, but we’re going to bypass that. The Command is just the wiring for the view and the appropriate method to execute. The Command shouldn’t know anything about the actual execution of methods, only that it needs to execute something. An addition to the Command is the possibility to know if it is actually allowed to execute some method. I’ll dig into this in part II of this blog.

The CommandAction is responsible for the actual actions that need to take place when a Command is executed. The CommandAction is also responsible for registering itself to the specific Command. I’ll dig into this in part II of this blog.

To make a real composite application, we need a way to let the independent modules communicate with each other. The EventManager will make this happen. Modules can request the interface to the EventManager, the EventManager will allow the module to register itself on specific Events or to Notify other Modules of a specific Event. It’s a basic publish subscribe pattern.

That’s a wrap for the architectural point of view for the MVVM pattern in Silverlight. In the next part, I will dive into the implementation of this.