MsBuild

MsBuild & Windows Services

Michael Stephenson — Sun, 23 Aug 2009 12:12:56 GMT

I've been revisiting a POC I did a while back that involved some custom Windows Service development. It reminded me that it's a little bit of a pain managing the clean and deployment of your Windows Services as part of your MsBuild script and I just wanted to make a few notes on this as a reminder to myself and potentially help others. The below will describe what I do.

Cleaning up

Typically this is the section that causes some hassle. The aim is to undeploy and delete any previous instances of the windows service and return the machine to a clean state before your build creates the system again. To keep it easy I have used the continue on error flag so if the services do not exist already the build will just continue (you could add stuff to check for the existence of the service). Often some of the problems I have had in the past here relate to the service being marked for deletion and not actually being deleted. The tasks I use in my script seem to deal with most occurances of that.

You can see in my below sample that I have 2 Windows services that I'm working with. The first thing I do is to use the SC command to stop the service. I then use the taskkill command to force it to kill the process if it hasn't been stopped yet. If you want a more elegant approach here you could probably create a custom task to wait until the service has stopped and then kill if it hasn't stopped within a certain time.

In my case I don't care about it being elegantly closed down as it's a development environment and I just want to get rid of the services.

After stopping and killing the service I then use the SC command to delete the service.

I could have used InstallUtil to uninstall the service rather than SC deleting it but in practice I seemed to have more occurances of the service being marked for deletion. If you get problems like this Avner wrote a quite useful post about this where he suggests some causes. The most common causes seem to be:

MMC being open and holding a reference to the service
The process is still running and your stop command didn't stop before the timeout (hence use of task kill above)

Deploying Windows Services

When it comes to deploying the services later in the MsBuild script after my code changes have been compiled I use InstallUtil to install my service. One point to note here is that if you specify to have a user account as the service credential then it will prompt you for the credentials which isn't very useful for an automated build script. I've seen some articles describing writing a custom installer so you can supply credentials from the command line which the custom installer will handle, but lets keep it simple. In my C# project I specified the installer to use the Local Service account and then after than in the below sample you can see how I use SC to configure the windows service to use the credentials and properties I want it to use.

Starting Windows Services

Finally before I start running some testing I want to make sure that my services are up and running so I use the SC command to start the services.

Summary

This approach while a little bit crude seems to be quite effective at managing the windows services in my MsBuild script and I haven't had to deal with the hassle they had been causing me. There seems to be forum posts discussing different problems people have had but I didn't come across anything which describes the overall approach like I've tried to do above so hopefully this is useful.

Configuration Manager - New Release

Michael Stephenson — Fri, 14 Aug 2009 22:35:17 GMT

Ive just released a new version of the configuration manager tool which I used in the BizTalk Light and Easy viewing video. This tool is used to help you manage the different settings needed for binding and configuration files across different environments and allows you to connect this with your build process.

The tool is available on codeplex at: http://configsettingstool.codeplex.com/

The light and easy video is at: http://blogs.breezetraining.com.au/mickb/2009/07/08/UnofficalLaunchOfTheBizTalk2009LightAndEasyWebCastSeries.aspx

Solution file version issue when migrating your Build Script to BizTalk 2009

Michael Stephenson — Sat, 04 Jul 2009 23:20:10 GMT

Ive just been working on upgrading the build generator to support BizTalk 2009 projects. While doing this one of the things i wish to do is to change the compile step to use MsBuild rather than dev env.

I found a little issue which others who use MsBuild may come across when migrating custom scripts.

Previously for BizTalk 2006R2 scripts I used to use the below command:

<Exec Command='"$(DevEnvPath)" $(SolutionName) /Build $(ConfigurationName)' />

This would compile the whole solution using devenv.

I changed the script to the following:

<MSBuild Projects ="$(SolutionPath)" Properties="Configuration=$(ConfigurationName);" />

and also changed the property on the project to use ToolsVersion="3.5"

This is how I expected the build to need to be and it would mean our script would take advantage of using the MsBuild task inline. When I ran the script I get the following error:

"Solution file error MSB5014: File format version is not recognized. MSBuild can only read solution files between versions 7.0 and 9.0, inclusive"

My initial thoughts made me think this was more complicated than it actually was. I was looking at using the Exec command rather than the MsBuild task for the compile which I could get to work. Then suddenly the answer hit me.

The problem was that I forgot that the .cmd file I use to call the MsBuild file was configured to use the v2.0 version of MsBuild rather than 3.5. As soon as I corrected this it worked fine.

So if you have the above error remember to double check the original call to start your build script wether it be from TFS/Cruise Control or a custom file etc.

Reconfigure BizTalk with MsBuild

Michael Stephenson — Thu, 05 Feb 2009 05:55:11 GMT

The other day I was having an issue with our build server so I decided to write a script to reconfigure BizTalk on our build or development servers. My plan was to run this regularly on a scheduled basis to ensure our build servers were kept clean.

I thought id write a little about this as it may be useful to others. Note the script is aimed at a single machine hosting BizTalk 2006 R2 and SQL Server.

Before I started I exported the configuration of our BizTalk Group to a file and then amended the credentials etc.

The list of tasks I would perform to clean and reconfigure our server is as follows:

Task	Description
Delete log file	When I run the BizTalk Configuration tool from the command line I will make it log to a file for troubleshooting any problems. Before I start the first clean up activity is to delete any old logs
Stop the following services: W3SVC SQLServerAgent	I stop any services which may want to access the BizTalk databases
Restart the following services: MsSQLServer MsDTSServer
Remove the EDI BAM definitions	When EDI is setup the BAM definitions for this feature are configured creating the usual BAM components. We need to remove these using BM.exe before we unconfigure BizTalk because unconfiguring the group will not remove the BAM Definitions
Use the BizTalk Configuration Editor to unconfigure the group.
Stop the WMI Service and any dependant services as advised by the BizTalk documentation
Delete the backup of the SSO Key	Note this is just for a development machine, you need to be careful about this on any real environment. I just delete the backup file here so I can recreate it when configuring the group
Unregister and delete the SSNS application for BAM Alerts	I will use NsControl.exe to do this
Run a SQL Script to drop the BizTalk databases
Delete the share and folder used by BAM Alerts	These are not removed when the group is unconfigured so need to be done manually
Start the following services: Winmgmt (and any dependant services which I stopped earlier) Start w3svc	Ensure any services which may be used while configuring BizTalk are started
Run the BizTalk Configuration Editor passing in the file containing the desired configuration.

To implement this I created a Visual Studio solution and wrote an MsBuild script and used some of the Microsoft.Sdc tasks. The below picture shows the files in this solution.

Its pretty simple and I will provide a link to the sample at the end of this post.

Some of the other ways I have extended this script since include:

Using an MsBuild task to register some custom adapters
Using an MsBuild task to register the WSE2 and Enterprise LOB adapters
Using an MsBuild task to add adapter handlers
Using the MsBuild configuration dictionary stuff I have blogged about in previous posts to configure the BizTalk Configuration xml file for different environments

The link to the sample for this post is: http://www.box.net/shared/t4k0m6ps5y

Dynamic BizTalk Versioning Strategy with Cruise Control

Michael Stephenson — Thu, 18 Dec 2008 22:03:04 GMT

Article Source: http://geekswithblogs.net/michaelstephenson

Versioning is one of the more difficult aspects of a BizTalk project mainly because of the ability to deploy side by side versions of the components within a BizTalk application and the fact that often a BizTalk project would require long running processes making it more difficult to do deployments. There are a couple of useful resources available on this area:

In his article Versioning and Re-Deploying BizTalk Server 2006 Applications Richard discusses some different scenarios about when you deploy side by side versions of BizTalk and makes some interesting observations. If you are new to versioning for BizTalk then this is good background reading.
In the MSDN documentation for BizTalk there is a page which discusses versioning and the 2 main strategies for it. This is useful but from my experience I think it misses a couple of things and is wrong in relation to the BAM files
This web cast includes a discussion around BizTalk versioning (mainly focusing on how to partition your BizTalk artefacts)
Nick Heppleson wrote an article about how you can use assembly redirection with BizTalk
There is also a new article on MSDN which provides some information similar to this article called Developing Integration Solutions using BizTalk Server 2006 and Team Foundation Server. Although again they explain how you could do versioning but don't seem to walk through their approach.

While all of these articles are great there is a gap in that nothing really talks about how to implement a versioning approach in your development process. In the rest of this article I will discuss some of the different considerations and how we implemented dynamic versioning for our BizTalk projects at my current project. I will also provide links to a sample which shows this.

Considerations for Versioning with BizTalk

There are a number of different things you should consider for your versioning strategy which are discussed below.

Type of Versioning

There are two main types of versioning which are discussed in the MSDN article above:

Static Versioning

In static versioning you would normally keep the Assembly Version Number the same all of the time and only increment the Assembly File Version with each build. This is the most common type of versioning approach I have seen used.

Dynamic Versioning

In dynamic versioning you would increment both the Assembly Version and Assembly File Version with each build. The most common way I have seen this implemented is to manually change these version numbers (this subsequently requires a number of changes to files within the project)

Deployment Pattern

The way you plan to deploy your application can have an affect on the versioning approach you might use.

Replace application every time

Some BizTalk applications implement processes where there are clear windows where a deployment can be done. There are no significantly long running processes and it is easy to drain the system of in process messages. In this case when you deploy a new version of the application you would be likely to completely remove the existing BizTalk application and then add the new version.

This approach is well suited to either of the 2 types of versioning.

Upgrade application

If you have a BizTalk project where you can not get a clear deployment window and you can not drain the system then your deployment approach needs to be able to support running multiple versions of processes at the same time. In this case you are essentially applying updates to your existing application and when the older instances have completed you may remove the old assemblies.

Latest Version for Development

One of the challenges is how within your code base you will implement these side by side versions and develop/test against them. When we deploy an official version we will take those assemblies and add them to an external libraries folder within our code base. When we build the code we will also deploy these older versions of the code and then run tests against this combined solution. One key thing we do is that we version the BizTalk project files in the code base to be version 999.999.999.999. When we do a local developer build we do not change the version numbers we only do this on our build server when the build is ran by Cruise Control. We need to ensure that the assemblies built from the code will always be the latest version when doing a developer build so we chose this approach.

What types of files do I need to care about for versioning?

There are a number of different file types you need to care about when applying versioning. In my opinion the above article on MSDN doesn't cover everything it needs to so here are my thoughts below:

Binding Files

We already use an approach of tagging the binding files to support changing the configuration for different environments based on stuff I have discussed before in other blog posts. In a binding file any references to assemblies will typically use the strong name for that assembly. When we apply dynamic versioning in the development process we will need to update parts of the binding file in each build to ensure the binding file continues to be valid.

If this is not done correctly the we could get problems importing a binding file.

Web Service Description Files

If you publish any web services from your solution then you may choose to save the web service description files and then regenerate the web services as part of your build. We save these files and have MsBuild tasks to support regenerating these web services with each build for WCF/WSE2 and standard SOAP web services. When we apply version updates we need to amend the WebServiceDescription.xml file that is published before we do the build.

Map Files

BizTalk Map files may contain references to assemblies if you execute an external assembly using the scripting functoid. We need to ensure these maps are updated if the assembly version is changed. If we do not do this we may get errors while executing the map.

Pipeline Files

BizTalk Pipeline files may have references to external pipeline components or schemas or other assembly references in custom configuration. If we apply dynamic versioning we need to be aware of the impact on these files and make appropriate updates to ensure the pipeline still works when it is compiled.

BAM Files

If you use BAM on your project then your solution may contain Tracking Profiles or BAM Observation Models. The BAM Observation Model does not contain information relating to assemblies, but if you use any Tracking Profiles (.btt files) then they may contain references to assemblies which may need to change as you change the version number. In the MSDN documentation it indicates that .btt files are in binary format which Im not sure is right as the ones on our project are clearly XML files. Based on our experience you can just update these files to change the version numbers.

One side comment is that you can also use the Typed BAM API project on CodePlex which will mean you don't have to worry about Tracking Profiles.

BRE Policies

If you manage your BRE policy as an XML file which you import and export then you may also need to update version numbers in it if you reference assemblies.

Configuration Files

Some configuration files in your solution may have assembly references in them. You may need to update the version numbers here too.

Our Versioning MsBuild Tasks

As you have read so far there are a number of different tasks which need to be done to implement versioning. We have developed the following list of MsBuild tasks which help us to do this in our MsBuild process. Note the code for these tasks is available in the accompanying sample.

BizTalkProjectAssemblyInfo

This task will look for any .btproj files within your solution directory (including sub directories) and then update the version attributes of the project file to take the value from Cruise Control

AssemblyVersion

This task will create a file called VersionNumber.cs which contains the C# attributes for versioning an assembly. All of the C# projects within our solution reference this file and pick up its version number when they are built.

ApplyVersionToAdhocFiles

This task is given a list of files which need to be inspected for versions to be updated. The task will use the assembly name regular expression, assembly public key token, assembly culture and assembly version regular expression to identify strong names within the file that need to be updated. Once a strong name is found the version number part of it is updated to the version passed into the task by Cruise Control.

Note that this task is also used to update any BRE policies which are stored as XML files in the solution.

ApplyVersionToWebServiceDescription

This task does the same as the apply version to adhoc files task however this task needs to force the file to be rewritten in a the right encoding for the web service publishing wizard to use.

ApplyVersionToBindingFiles

This task is given a list of paths to binding files which it needs to update. In the binding files it will look for strong names in the same way as the adhoc files task and update them. In binding files there are also some other formats in which assembly version numbers are stored so this task will also handle these to ensure that the binding file is correctly updated.

ApplyVersionToBizTalkArtefacts

This task will start at the root directory of the solution and look for all BizTalk artefacts which may require updating (Maps, Pipelines, Tracking Profiles). For each of these file types it will look for assembly references based on the strong name patterns provided and apply the updates to the version numbers which come from Cruise Control.

Walk Through

Setting up a new solution to use dynamic versioning

When we are starting with a new solution and we want to be able to implement the dynamic versioning straightaway there are a couple of standards we use.

C# Project Files

In our solution it is common to have C# projects to compliment our BizTalk projects. We take the approach of versioning these assemblies by adding an existing file to the project which includes the below code snippet (we usually call this file VersionNumber.cs and it is located in the root folder of the solution). This means that the assemblies are all versioned to the standard 999.999.999.999 during development

When our MsBuild process executes it will overwrite this AssemblyVersion.cs file and replace the version numbers in it to the version label taken from cruise control. We use our AssemblyVersion custom MsBuild task. There are a number of different tasks in the community and Microsoft.Sdc tasks which can do versioning of C# projects and using any of these should be sufficient.

BizTalk project version numbers

On all of the BizTalk projects within the solution we will amend the project properties (see pic below) to set the version attributes to the fixed 999.999.999.999. This will mean during a local developer machine build all of the BizTalk assemblies will be versioned as 999.999.999.999. When Cruise Control runs a build the extra build tasks will run and execute our BizTalkProjectAssemblyInfo custom MsBuild task. This will update the version numbers of all of the BizTalk project files within our solution to apply the version number from Cruise Control.

Other Artefacts

As we will have applied the 999.999.999.999 version number to our projects before we start adding artefacts to the projects then any files we add will correctly pick up these versions and we will not manually need to update them.

The Cruise Control Integration Bit

In the below picture you can see the Cruise Control configuration used for the Continuous Integration of this solution. In the tasks bit you can see we basically call 3 MsBuild scripts as follows:

Apply versioning to the files in the solution
Perform a debug/development build of the solution (including executing tests)
Perform a release/deployment build of the solution (including executing tests)

The bit we have added is the first step where we will call ccnet.targets MsBuild script. This file is in the solution and is where we will call the tasks to apply versioning.

Setting up the CCNet.targets File

The below picture shows the contents of the ccnet.targets file. This file will basically call the list of MsBuild tasks in the ApplyVersion target which will apply versioning to all of the appropriate files. Each of these tasks was discussed in detail earlier in this article.

In the property group at the top of this file you can see that we have defined some common attributes which each of the tasks uses to do its job. These properties are used as follows:

Property	Notes
AssemblyNamePattern	This is a pattern used to identify the name of assemblies. In our case the assemblies will usually be called something like Acme.Something.BizTalk…. We use the regular expression Acme.Something.BizTalk.?\w* which will find assemblies with the right names for us for example: Acme.Something.BizTalk Acme.Something.BizTalk.Orchestrations Acme.Something.BizTalk.Schemas
AssemblyCulture	All of our assemblies have the culture neutral so we use this as a static value in the script
AssemblyPublicKeyToken	All of our assemblies have the same strong name applied usually so we can just keep this as a static value of the public key
AssemblyDynamicVersionPattern	This property is a regular expression which you will use to identify version numbers that need to be changed. In our case because we use the fixed version 999.999.999.999 to indicate it needs to be dynamically changed we just use this value. Having this as a regular expression however allows some flexibility on how you might use this

As you can see from the order of calls to our tasks we version the files in the following order:

BizTalk project file
C# project file
Adhoc Files
Web Service Description Files
Binding Files
BizTalk Artefacts

The order here isn't really that important as long as all of these activities are done before compiling the solution.

Converting an existing solution to use dynamic versioning

This walk through will explain how to configure an existing BizTalk solution to use dynamic versioning rather than static version approaches described above. One key point to reiterate here is that on a developers machine we always do builds as our fixed 999.999.999.999 version number and it is only on the continuous integration build server that we run the additional tasks to do full versioning as described below.

Reconfiguring parts of the solution

C# & BizTalk Project Files

We will need to update the BizTalk and C# projects to reference the 999.999.999.999 version number. We can do this the same as how is described in the section about setting up a new solution for dynamic versioning.

Updating Map Files

Maps are slightly strange. In the map if you reference an external assembly and execute it via the scripting functoid then you need to be aware that the strong name for executing assembly may need to change. In the MSDN documentation explaining this it indicates you need to change maps, but if you disassemble an assembly containing maps and the C# project was referenced as a project assembly then the compiler seems to change the xslt within the map for you. However as this is a little unclear we decided to change the maps anyway.

To do this we needed to open the map using the XML Editor in Visual Studio. We then would change the version numbers highlighted below as 1.0.0.0 (in the pic below) to 999.999.999.999 for all of the assemblies we know we are going to dynamically version.

We would do this for every map in the solution. When Cruise Control runs the build it will modify and strong names in .btm files which need to be versioned.

Pipeline files

Pipelines are similar to maps in that under the .btp file is XML which may contain assembly strong names (see picture). Again we would open the file using the Visual Studio XML Editor and change the version numbers from 1.0.0.0 to 999.999.999.999 for any references to assemblies we are going to dynamically version.

When the build is ran by Cruise Control our additional tasks will find all of the details we need to change and modify the .btp file before it is compiled.

Binding file template

In the solution we have a template binding file which contains tags which we use to configure the binding file for different environments. In a binding file there are lots of references to assemblies by their strong name. If we have any assemblies which we know are going to be dynamically configured then we will replace their version with the fixed 999.999.999.999. In the below picture you can see an example binding file template which shows the version numbers before they have been amended.

When Cruise Control runs our build then an additional step is ran which will execute our ApplyVersioningToBindingFiles task. This will modify the binding file correctly to replace the version numbers with the appropriate label from Cruise Control.

Configuration Files

In some of our solutions we include configuration files which may have assembly version numbers in which need to be dynamically versioned. We follow the same approach to make the version number 999.999.999.999 if it needs to be dynamically configured.

In the Cruise Control build a task called ApplyVersionToAdhocFiles is called passing in a list of these adhoc files.

Web service description Files

In some of our solutions where we publish web services from BizTalk we use a couple of MsBuild tasks in our build process which will support regenerating these web services each time the build is ran by using the WebServiceDescription.xml which is produced by the Web Service Generator Wizards. We have MsBuild tasks which support WSE2, SOAP and WCF.

When we use this technique we also need to apply updates to any version numbers which may need to change in the WebServiceDescription .xml. To do this we use the same approach of replacing the versions with 999.999.999.999 for the developer build and then Cruise Control will run the ApplyVersionToWebServiceDescription task to do the dynamic updates.

BAM Tracking Profiles

The BAM tracking profile is an XML file under the hood and we again replace the version number of any of our assembly strong names with 999.999.999.999.

When the Cruise Control build runs it will execute a task which will apply the Cruise Control version label in place of our version number and then when the build deploys BAM artefacts they will be already versioned correctly.

(For details of how we integrate BAM into our MsBuild process please refer to: http://geekswithblogs.net/michaelstephenson/archive/2008/06/15/122870.aspx)

BRE Policy Files

When we use BRE we usually take the approach of managing the policy as an artifact in the solution. We use custom MsBuild tasks to import and export the policy from BRE and store it in the solution as an XML file. If we reference any assemblies in the policy that need to be versioned then we will amend the xml that is exported from BRE and make the version numbers the usual 999.999.999.999. In terms of Cruise Control we treat the BRE exported XML file the same as an adhoc file which requires version updates. We then use the ApplyVersionToAdhocFile task to update this

If you would like to know more about how we implement the BRE features of our build process please refer to the following article: ???

!!!!!! vWhere is BRE post !!!!!

Check local build

Finally when we have done all of the above steps we will run a local developer build to see that the solution is fully versioned, compiles correctly and deploys. We also ensure that the build has ran our BizUnit tests and they are all successful.

The next stage is to get Cruise Control to so some extra stuff.

The Cruise Control Integration Bit

When modifying an existing solution to use dynamic versioning, the requirements for the ccnet.targets file and Cruise Control to implement the version updates is exactly the same as when you setup a brand new solution for dynamic versioning. For details please refer back to that section.

Summary

At this point you can see it is a fair about of work to modify an existing solution to use this versioning technique. I think the earlier you do it in your project life cycle the better. You can use things like Replace All to modify some of the version numbers manually when doing the above tasks but be careful when doing that as you may not want to change all version numbers.

Frequently Asked Questions

In relation to this topic the following questions have occasionally came up.

How do I do side by side versioning in development for a new major release?

The approach described in this article is entirely intended to support development of side by side versions of the same solution. Imagine you have version 1.1.0.0 of your application deployed and we know you want to now work on version 2.0.n.n. You know from your understanding of this topic that you will employ a deployment model which will mean you will have multiple versions of some of your assemblies deployed.

The way you could implement this is to add external Library folder within your solution store the version 1.1.0.0 versions of all of the deployed assemblies. You could also store the appropriate development binding files and any other artefacts to support this update. In your build script you might setup and deploy the existing application (v1.1.0.0) and then modify your build script to apply updates to the application by deploying some or all of your newly compiled code.

In development the newly compiled assemblies always have a very high version number they will always be the latest version and the versioning rules will apply correctly. You will probably also do things like modify binding files to be able to work with two versions of the assemblies. In the binding file remember that the way we do this only our assemblies which are versioned 999.999.999.999 are dynamically changed so if you add details of an older version of the assembly to the binding file we will not touch that instance of a string name as the version number within the string name will not be 999.999.999.999.

When your code is checked in and build on your build server Cruise Control would apply the correct 2.0.n.n (provided you have updated the major number in its config) version number and your build will allow you to have a correctly configured and working side by side versions of the application.

What's the 999.999.999.999 thing all about?

In applying dynamic versioning to the solution we need to be able to ensure that in our development environment a developer can work on a solution which may have side by side versions. We have chosen to use 999.999.999.999 to indicate this is a developer machine only version of the assembly and it is given a high version number to ensure that when it is build it will always be the latest. Although the build tasks accept a regular expression for the version number which needs to be replaced we find it keeps things simpler by always using this fixed number.

Because we use source control we can not apply dynamic versions on a developers machine local build because the files we need to modify will be read only. A developer will always build version 999.999.999.999 of the solution. When the developer checks code in Cruise Control will replace all of these developer 999.999.999.999 versions with the build label from Cruise Control.

BizTalk 2009 Update

Following the release of BizTalk 2009 CTP I have had a brief look at how the new version would affect this versioning approach. In my opinion the approach stays very much the same with the exception that now BizTalk project files are MsBuild based and you can use the AssemblyInfo file to version the assembly rather than the old BizTalk project file. Based on this the change to our implementation would be to not use the old VersionBizTalkProjectFile task and just use the C# one for BizTalk projects as well.

Summary

As you can see from this article this isn't a trivial undertaking. If you do it right from the start of the project then hopefully you will find things a lot easier.

Hopefully this article will plug the gap I identified at the start and there is now a detailed walk through of applying effective dynamic versioning to BizTalk projects which use continuous integration. If you would like to look at the code for the MsBuild tasks we used to help us implement this approach then please refer to the following location:

http://www.box.net/shared/7ebfbdjau0

(Note some companies block access to box.net so if you are unable to get the sample please email me via the blog)

I hate days like this

Michael Stephenson — Wed, 13 Aug 2008 00:38:08 GMT

Had one of those days yesterday and today, you know what its like when you find a bug/problem and you dont really get a chance to properly look at it when your doing a million things at once.

It is so often that the cause of the problem is really obvious but you just cant see the wood for the trees.

This is a reminder for myself as much as anything.

I was writing an msbuild task to wrap cruise controls ICruiseManager so I can get the latest build label of a project that has been built.

The problem was that when I tested the task using MsTest from Visual Studio it worked fine, but when I ran it from an MsBuild script it kept failing complaining about not being able to find the ThoughtWorks......Remote assembly. I ensured that the assembly was where my tasks assembly way and frustratingly it wasnt working

When my brain returned I spotted that the problem was that the assembly is being searched for in the directory which the process started (the .net framework directory where MsBuild.exe is) so by copying the assembly there it now works.

BizTalk Documenter in my build

Michael Stephenson — Tue, 05 Aug 2008 05:17:43 GMT

From previous posts you may have read how I integrated the Microsoft BizTalk documenter into my MsBuild process.

In general this has been working fine, but every now and again I kept getting a build failure when trying to generate the documentation as follows:

System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Documents and Settings\<UserAccount>\Local Settings\Temp\BTS2K4Doc\Application\fb7b6ba7-016c-4a1f-9c7d-ec9037911456.html'

If you get this it seems to be caused by an hhc.exe (Microsoft Help Compiler) process still being alive from a previous run. Just kill it and the builds will work again.

MsBuild Task for consuming WCF Services

Michael Stephenson — Tue, 29 Jul 2008 06:16:04 GMT

Article Source: http://geekswithblogs.net/michaelstephenson

Recently at the UK SOA/BPM User Group Yossi Dahan and I chatted briefly about using MsBuild and BizTalk, more specifically Yossi mentioned that he wished it was possible to regenerate the schemas for consuming a service automatically.

Following this discussion and a few other things I had a blast at seeing how difficult this would be to do. I think there is a lot of value in having this approach as it fits well with a contract based development approach and continuous integration. I want to be able to regenerate my schemas every time I build the solution, and if a breaking change has been introduced I want the solution to break so it is corrected.

This fits with what I believe is a good practice to identify these kinds of problems as early as possible in the development cycle.

The aims of the task are:

Act in a similar way to the Generate Schema feature for BizTalk/Visual Studio except that it will be driven by an MsBuild task rather than a GUI
Just deal with the schemas, I wasn't too bothered about regenerating the orchestration and binding file samples

(The sample is available for download at the bottom of the article)

The Sample

In the sample the quickest way to demonstrate this is as follows:

Modify the BuildProcess.xml file to point to your url for the MexEndpoint
Double click the RunBuild.cmd file
Check the Acme.BizTalk.Schemas.WCFService folder and you should see your schemas have been updated

It is expected that you would include the schemas in your project, but exclude them from source control so they can be rebuild every time you build the solution.

Digging Deeper

I managed to work out how to do this by inspecting the Microsoft.BizTalk.Adapter.Wcf.Consuming with Reflector. Upon investigation it would have been nice if a few of the classes were externally available from the component. As it was I needed to disassemble the component to progress this idea. In the disassembled component I created a new version of the Consumer class in which I removed some of the functionality and changed the Consume method interface so it wasn't dependant on being passed a Visual Studio Project object.

With a couple of other tweaks I was able to get this working

Conclusion

Although this task seems to do the job, it has not been extensively tested, and it also only currently works with the MEXEndpoint and not yet with meta data files.

Hopefully this idea will help a few people, and the idea might get back to the product team as a possible future enhancement as this kind of thing can certainly help your development process be more effective.

BizTalk MsBuild Generator

michael stephenson — Sat, 16 Feb 2008 07:40:07 GMT

I created this tool ages ago and have been using it on projects for a while. Ive eventually got around to cleaning it up and doing some documentation for it so I have now made it available on CodePlex.

Basically the tool allows you to generate an MsBuild script which will let you do all of the build and deployment actions to compile and deploy your BizTalk solution.

It also produces a script which is well structured and easy to extend.

If you want to know more check out: http://www.codeplex.com/BizTalkMsBuildTool

MsBuild Task for WCF Service Publishing for BizTalk

michael stephenson — Mon, 04 Feb 2008 00:12:48 GMT

A number of months ago I did a couple of posts about how we integrated the Soap and WSE web service publishing wizards into our build process as MsBuild tasks. These posts are located at the following url's:

Soap Adapter: http://geekswithblogs.net/michaelstephenson/archive/2006/09/16/91369.aspx

WSE 2 Adapter: http://geekswithblogs.net/michaelstephenson/archive/2006/09/16/91371.aspx

Now that BizTalk 2006 R2 is around I want to have the same approach for the WCF Publishing Wizard.

Before I get into the details of this, it is important to note that WCF provides a hosting model that means you do not need to host services in IIS and they can be hosted by In Process BizTalk hosts. Although this is cool, there are still a number of reasons you may still want to host the services in IIS.

Aim

The aim of the task is to allow you to regenerate the services which are published as part of your build script. This means if for example your schema changes then the published service is automatically updated for you each time you build the whole solution. This also fits well with a continuous integration strategy.

Process

The development process or approach I use in these situations is as follows:

1. The first time you produce the wcf service you will manually use the WCF Publishing Wizard and generate the service as desired.

2. In the published service there is a temp file called WcfServiceDescription.xml. Take a copy of this and add it as an item to your solution.

3. In your build script call the custom task we will create and pass in the path to the WcfServiceDescription.xml file in your solution.

In this process it is important to note that if you need to add any new schema or orchestrations to the published service you will need to generate the service again by hand to get in there new items, and then simply overwrite the description file in your solution.

Using the task

The following picture shows the sample of the build script using the task.

As you can see above the call to the task is very simple.

Inside the Task

The task itself is very simple and basically references the Microsoft.BizTalk.Adapter.Wcf.Publishing assembly and then executes the following code in the Execute method of the task.

Again the code is very simple

Things to watch for

There are a couple of things to watch for when you use this approach:

Ensure in the service description file you have the overwrite property set to true. If not then if the service is already published you will get an error
I would also recomment setting up the application pool and virtual directory in IIS yourself as part of the build script. This gives you full control over how it is created where as if you let the Wcf Service Publisher do it then it will use some default settings which you probably wouldnt want to use in practice

Summary

I hope you file this task useful, it is a little simpler that the previous ones, particularly the WSE 2 one which unfortunately had that bug we had to work around. If you would like to check out the sample then see below where the source code is available.

Disclaimer

I have noticed a few sites that seem to copy the content of blog articles and display them in their own site. It is a bit annoying that they do not clearly reference or acknowledge the author so I have decided to put this note on the bottom of all of my posts from now so it is clear who wrote it.

This article was written by: Michael Stephenson

The source of this article is: http://www.geekswithblogs.net/michaelstephenson