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.

SharePoint 2010: Business Connectivity Service Part I

At this point there is still a lot of confusion surrounding the name of the new Business Data Catalog. In SharePoint 2007 it was Business Data Catalog in 2010 it’s Business Data Catalog or Business Connectivity Services or External Content Types. In Visual Studio 2010 it’s still Business Data Catalog and in SharePoint Designer 2010 it’s called External Content Types, but what’s in a name? I’ll call them Business Connectivity Services.

In SharePoint 2007, the BDC lacked any form of UI, but in 2010 that has changed! You can find the Business Connectivity Services under: Central Administration –> Manage Service Applications –> Business Data Catalog. My preferred weapon of choice is Visual Studio, but if you want to do the basics then you can use SharePoint Designer (it’s a lot friendlier). When you’re trying to integrate with a very basic WCF service or SQL database or even a .dll (!!) SharePoint Designer is the way to go. For all your other services (or custom work) use Visual Studio.

For this first part I would like to do a basic thing. Staying close to the old BDC way. The BDC works with a Finder and a Specific Finder method. The Finder method returns a list of arbitrary items and the Specific Finder returns an item based on the ID of that item. I also want to do some custom work, so I won’t be creating my own webservice that has those two (Finder, Specific Finder) methods, that would be too easy.

I found a webservice at: http://www.webservicex.net/country.asmx that returns a string, but the string is an XML DataSet representation of a list of countries. If you try to set this thing up with the old BDC you’ll only get one object with a string in it. In the new BCS you now have the ability to customize the Finder and Specific Finder methods.

First you have to install the Microsoft Visual Studio 2010 tools for SharePoint 2010. Start Visual Studio 2010 and create a new Business Data Catalog model from the SharePoint 2010 projects.

The Business Data Catalog Model starts with a basic model with Entity1 and an Entity1Service. If you run this project and create an external list in SharePoint, you’ll see your first BDC application running in SharePoint.

Visual Studio now has a great new designer for the BDC Model and it’s a good one. Another good thing is, is that everything is XML. You can edit the DataCatalog files in the XML editor, I don’t recommend it, but you can. Stay in the BDC Explorer for now, it has everything we need to do. Go to the Solution Explorer and we’ll start by renaming the Entity1 to Country and remove all of the properties of it. Add three new properties to Country: IsoCode, Name and Currency. Add a Web Service Reference to the project for http://www.webservicex.net/country.asmx. Go back to the BDC Explorer and open BusinessDataCatalog1. You will see that there is still an Entity1 in there, rename it to Country. Rename Identifier1 to IsoCode and rename the methods to FindAllCountries and FindCountryByIsoCode (Finder and Specific Finder). I found a bug in this release; whenever you rename a method in the BDC designer it automatically creates a new method in your service. I hope they’ll fix this in the Beta1.

In the BDC Method Details you’ll see all the details of all the methods. You’ll find that there will still be references to Entity1 or Identifier1. You can change these to Country and IsoCode respectively. One thing you should realize is that you’re now creating a model on top of the Country and CountryService classes. Make sure that all the names and objects in your model have underlying C# properties and classes. If you select the FindCountriesByIsoCode method in the BDC Explorer, you can open the combobox for Country (or Entity1 if you forgot to rename it) next to returnParameter and click on Edit. You’ll jump to the BDC Explorer and see the Model version of Country. Make sure that all the properties of Country are in the Model version, with the right name and type name. You can add “Properties” by right clicking on Country and select “Add type descriptor”.

When you’re done, your BDC Model should look something like this:

If you’ve done all of this correctly you can go to the CountryService.cs (in the Solution Explorer) and start coding on the FindAllCountries and FindCountryByIsoCode methods. When you’re all done do not forget to copy your serviceModel settings (app.config) to the SharePoint web.config file. (The automatic deployment in Visual Studio works great, but it forgets configuration settings). If you’ve done all of this correctly, then simply press F5 and navigate to your external content list and you’ll see this:

Workflow 3.5 Designer Rehosting

Since the release of Workflow, Designer Rehosting has been promoted as one of the good qualities of Workflow. In each article or presentation Designer Rehosting keeps coming back as a good thing. So I decided to put it to the test. I started with trying to find a reason why a customer would want to use Designer Rehosting. Microsoft gave me the following reasons:

• (Design Time) To view, create or modify Workflows
• (Runtime) To view the current state of an executing workflow by utilizing the tracking information.

Both reasons are obvious and still don't give me any reason to sell it to a customer, they can use Visual Studio to do exactly the same. There's another reason why your customer might want to use Designer Rehosting. Maybe in some sort of specific scenario he wants to customize views to his needs or choices. With Designer Rehosting you can choose to expose as much or as little functionality of Workflow as you wish.

I started with catching up on Designer Rehosting, MSDN has some great articles on that, you can find them here. Microsoft made some sample bits to get you up to speed, those can be found here. After I read the documentation (that's a lie) and grinding the code, I tried to do it myself. I must admit, I expected it to be easier. The actual hosting WF in a Winforms app is easy, but to put something of a framework together that was hard. Maybe I should have just copied all the code from the sample bits, but I hate to do that.

All the things you need to get your view in order can be found in System.ComponentModel.Design. I used the WorflowView, DesignSurface and the WorkflowDesignerLoader to get my View in order. After a little bit of yelling and screaming at my PC, the view looked like this:

The thing that got me screaming was the toolbox control, I expected that this toolbox would be in System.ComponentModel.Design, it was not. I did not find a control that showed me all the Activities from System.Workflow.Activities, so I ended up making the thing by myself. I don't know why Microsoft chose to not expose that control, but it sure would have helped me. Then again I'm now able to (for example) let the InvokeWebServiceActivity disappear from my toolbox, or show one of my own custom Activities.

So now I'm able to drag and drop my Activities to my Workflow, that's cool! This is the basics on Designer Rehosting. I can load a Workflow and show it in my app. I didn't have time to get the Tracking ready, that will be my next project and just for fun I want to be able to add some code, but that's a whole different ballgame.

To be honest I think that you should really think about if you want to use Designer Rehosting. It sounds easy and they make it look like you really want to, but you need to write a lot of plumbing code before you even have a simple app like this. I don't think there will be a lot of customers that really need Designer Rehosting, there are usually other (better and simpler) solutions for the same problem.