Geeks With Blogs

News View Michael Stephenson's profile on BizTalk Blog Doc View Michael Stephenson's profile on LinkedIn
Michael Stephenson keeping your feet on premise while your heads in the cloud

Ive been developing a few custom adapters for a project recently.  Actually one of the adapters was the .net file adapter from the BizTalk SDK samples which we wanted to use and include in our deployment.  The aim was as follows:

  • Create the functional code for the adapters
  • Create unit tests to cover as much of the functional code as possible
  • Create a sample BizTalk application to allow demonstration and further testing of the adapters
  • Create BizUnit tests to test the adapters within a BizTalk application
  • Integrate the adapters solution into Continuous Integration
  • From each build produce a deployment package so the adapters could be easily and reliably deployed

In setting out to do this I did most of the tasks including preparing the build scripts using MsBuild like we do for all of our solutions.  The scripts basically do the following tasks:

  • Clean the environment, removing any custom hosts, deleting the adapters if they have been previously deployed and removing locations that might have been setup from a previous build
  • Compile the source code
  • Setup the environment including custom hosts, recieve locations etc etc
  • Register the adapters in the registry
  • Add adapters to the management database
  • Deploy the biztalk sample/test code to a BizTalk application setup for testing
  • Deploy bindings for the test cases
  • Run all of the testing
  • Package the sample application into an msi
  • Package the adapters into an msi

I have plenty of experience in setting up these build scripts now and we actually have a tool that does a lot of this for us, but I came across a strange situation with this script.  Basically when the script was run on a clean environment then it always worked.  However when it was ran again and the environment was cleaned by the script I started having a problem which manifested itself during the compile.  Sometimes the .net file adapter couldnt compile due to a lock on the file.

The other adapters were mainly send adapters but this one was a polling recieve adapter.  It seemed that the adapters previous setup had been cleaned properly but I regularly got this problem.

After a very painful debugging experience I found that the cause of the problem was that during my clean up there is a task which stops the BizTalk application.  This task uses ExplorerOM to stop the application.  The code in ExplorerOM causes the design time part of the adapter to be loaded when the call to stop disables all of the recieve locations.  This then causes the process to keep a lock on the design time assembly.  The lock was held by msbuild and it was released when I closed the build script.

I tried numerous things to try and resolve this, but in the end I resolved for bit of a hack, but it does the job.

I adjusted the build script so rather than calling the target containing the stop and remove using the CallTarget within MsBuild I used the Exec task to start a new MsBuild process which called this target.  When the application was stopped and removed this new process would then complete meaning that the process locking the file would exit.  The dll was no longer locked when I came to compile it again.

The main build script waited for this new process to complete then continued and because the lock was no longer there the rest of the build now works everytime.



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:

Posted on Tuesday, December 11, 2007 12:49 AM BizTalk | Back to top

Comments on this post: Interesting little trick in my adapter build process

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Michael Stephenson | Powered by: