Thursday, September 13, 2007

Migrating BizTalk 2004 (VS 2003) Solution to BizTalk 2006 (VS 2005)

While the BizTalk Server product team has done a commendable job of being able to migrate an already deployed BizTalk 2004 solution to BizTalk 2006 in-situ, there is definitely some effort in upgrading the Visual Studio solution itself such that subsequent deploys actually work.

The situation is complicated by two things: the change in project definitions between VS 2003 and VS 2005, and of course the migration from .NET 1.1 to .NET 2.0 (there should be no complication by .NET 3.0 with BizTalk 2006 R2 as .NET 2.0 exists as-is in 3.0).

Depending on the solution, some of the following items may not apply, and there may be other items not mentioned you will need to take care of (ie referencing deprecated classes, method overloads etc).


  1. Migrate the solution to VS 2005 by simply opening the VS 2003 .sln file.  Complete the steps of the solution migration wizard.  This will generate a report of the items you may need to fix (esp deprecated classes)
  2. Once in the solution, at the BizTalk Project level you will need to do the following:
    1. If you have web references in your project, you will need to rebuild them.
      1. Delete each web reference and re-add them with the same name
      2. If you use Dynamic web references, ensure that property is selected
      3. Add a reference to System.Configuration if it is not there already (the compiler will fail otherwise)
    2. Open the project's properties
      1. Assign a default BizTalk Configuration Database
      2. Assign an Application Name
  3. For each schema in your solution that uses promoted properties
    1. Open the 'Show Promotions' dialog.  This will rebuild the xsd's code-behind (.cs)
  4. For each orchestration with a web-port
    1. Delete the configured web port (since you regenerated the web reference)
    2. Re-add the web port with the same name, ensuring it is a Dynamic web port if necessary
    3. Re-assign message types for messages defined in Orchestration Explorer
    4. Re-connect send/receive shapes if necessary
You may find after your first build there are new warnings.  Some warnings have been added to assist in improving the performance/stability of your BizTalk solution.  The one most notable to my solution was the following:

Performance Warning: marking service 'OrchestrationName' as a longrunning transaction is not necessary and incurs the performance penalty of an extra commit

For orchestrations where long-running was not necessary (ie do not contain send/receive pattern or other long-running transactions), I have since changed them to use Transaction Type of None.  Hopefully we will see a reduction of database chatter for these orchestrations when we benchmark the changes.

Clearly the migration is not trivial, though hopefully yours is smooth and relatively quick.

1 comment:

Prashanth Patali said...

Thanks for sharing these steps, Benjamin! It helped me in my migration steps.