Monday, September 25, 2006

Migrating a BizTalk 2004 Solution to 2006

We have been developing a large enterprise workflow solution using K2.Net, BizTalk 2004, SQL Server 2000 on a Microsoft.Net 1.1 platform for the last few months. Our development strategy uses Virtual PCs to recreate the customer's environment minimizing deployment risks associated with developing large scale solutions. Our customer recently asked us to upgrade the solution to use BizTalk 2006 with SQL Server 2005 on a Microsoft.Net 2.0 platform. While most migrations require the upgrading of the BizTalk server for which there is quite a bit of documentation (see links below), we decided to create a new Virtual PC with a fresh installation of BizTalk 2006.

After starting up the new VPC and load the solution from source control I checked out the solution (I recommend you label your version of the solution in your source control system to make it easy to roll back should any issues arrise). From here the steps simple enough:

Visual Studio Conversion Wizard
  1. Step one requires running the Visual Studio Conversion Wizard. Open the solution with Visual Studio 2005.
  2. The Visual Studio Conversion Wizard starts up with a "Welcome" screen (click Next)

  3. A "Ready to Convert" screen (click Finish)
  4. I received a couple of warning messages, the first asking if I'd like my database project which uses an OLEDB provider for SQL Server upgraded to use the .Net Managed Provider for SQL Server. I chose Yes.

  5. The second warning message related to Web projects being converted to the new Web Site format. It removed all source control bindings.

  6. The "Conversion Complete" screen with the option to show the conversion report checked (click Close).
  7. The Conversion Report loaded within Visual Studio giving the results of the conversion process.

External Components
  1. Step 2 requires installing the new versions of external components, e.g. Enterprise Library for .Net Framework 2.0 and NUnit 2.2. Update the references in the solution projects and any obsolete method calls.
GAC Build Events
  1. Step 3 involved changing all build events used in project properties to add assemblies to the Global Assembly Cache (GAC). These are used in C# projects that are referenced from BizTalk and as such need to be added to the GAC. This requires a change in syntax as listed below:

    Visual Studio 2003:
    i. Pre-build: "%VS71COMNTOOLS%vsvars32.bat" && gacutil /u $(TargetName) ii. Post-build: "%VS71COMNTOOLS%vsvars32.bat" && gacutil /i $(TargetPath)

    Visual Studio 2005:
    i. Pre-build: call "%VS80COMNTOOLS%vsvars32.bat" && gacutil /u $(TargetName)
    ii. Post-build: call "%VS80COMNTOOLS%vsvars32.bat" && gacutil /i $(TargetPath)
External Strong Name Keys
  1. Step four required making Visual Studio 2005 use external strong name keys for signing the assemblies (to add assemblies to the GAC they need to be signed with a strong name key). The reason that I wanted to do this was two fold:
    • When trying to build the project in VS2005 the following compiler warning appears
      Use command line option '/keyfile' or appropriate project settings instead of 'AssemblyKeyFile'.
    • If you use the properties page to sign the assembly by selecting the strong name key it copies the key to your project file. This becomes a maintenance issue if you have multiple projects signed by the same key. You have all of the keys copied to mulitple project folders and duplicated in source control.

    Thanks to David Kean's blog on How to make Visual Studio 2005 use external strong name keys that managed to solve these issues. I've listed the steps here on how to do this with one extra step that I was required to take to get my projects to build.
    • Open the project file (.csproj) in a text editor.
    • In the tag under the tag, enter either an absolute or relative path to the key file, e.g. ..\..\Common\MyKey.snk.
    • Save the file and reload the project file in VS2005.
    • Right click on the project and select Properties. Select the "Signing" tab and check the "Sign the assembly" checkbox. The dropdown list below should show the path to the file e.g. ..\..\Common\MyKey.snk.

    For BizTalk projects, Right click on the project and select Properties. The Property Pages dialog box should appear. Navigate to Assembly under Common Properties and enter the path next to the "Assembly Key File" property. See the diagram below:


Finally
  1. Lastly, change any recommended warning issues that may arise. E.g. when using values from the tab in a configuration file the coding change required is as follows:

    Visual Studio 2003
    ConfigurationSettings.AppSettings["mySetting"]

    Visual Studio 2005
    Configuration.ConfigurationManager.AppSettings["mySetting"]
    Note: You need to add a reference to the System.Configuration.dll.
BizTalk Migration Links

Monday, September 18, 2006

Workflow: WF, MOSS & K2.Net

After recently attending a course at the SourceCode head offices in Redmond, I started wondering about the affect that the release of Windows Workflow Foundation (WF) would have on their workflow solution product, K2.Net 2003 and their upcoming release code named "Black Pearl". When would you use K2.Net as opposed to WF and vice versa? Having worked on a couple of workflow solutions in the last few months, one implementing a K2.Net solution, and another a WF solution using Microsoft Office SharePoint Server 2007 (MOSS) - which is still in beta version, I have had an opportunity to see both tools in action.

The Tools

Windows Workflow Foundation (WF):
WF is the programming model, engine and tools for quickly building workflow enabled applications. It’s a part of Microsoft .Net 3.0 (previously WinFX). Developers need to design, code and run business process workflows applications using Visual Studio.

Microsoft Office SharePoint Server 2007 (MOSS):
MOSS serves as an enterprise collaboration system, allowing for managing content and business processes. It implements WF to facilitate basic content and document approval and provides the host application for WF to run workflows.

K2.Net 2003 & "Black Pearl":
K2.Net is an enterprise workflow platform able to host workflow solutions built on Mircrosoft.Net. It comes with the following tools:
K2.Net 2003 Studio – used to develop the workflow.
K2.Net Workspace – with reporting, task redirection,
K2.Net 2003 Service Manager – with server properties, error handling, user and group permission settings, task redirection, and security settings.

K2.Net “Black Pearl” will be built on .Net 3.0 (including WF) with the development studio being able to plug into the Visual Studio. My understanding is that their development team has been collaborating with the Windows Workflow Foundation and Office 2007 team for a couple of years and it will integrate with SQL Server 2005 and Office 2007. “Black Pearl” will also serve as the host application for WF providing an enterprise workflow solution platform. It’s slated to be released sometime in 2007.

How they fit together

While anything can be built from the ground up, WF provides a foundation for creating workflows. MOSS leverages WF to provide simple workflow scenarios that can be used through its collaboration environment. K2.Net provides a platform of ready made activities and events allowing for rapid workflow development. It has pre-built reporting, management and user workspace modules.

Ultimately the answer comes down to the complexity of the workflow and whether you want to spend time coding the infrastructure or use a ready made enterprise environment and build the workflow.