Sergio Del Piccolo

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.

1.  
   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.
   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)
   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.
   • 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.
   • Open the project file (.csproj) in a text editor.
   • In the AssemblyOriginatorKeyFile tag under the PropertyGroup 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.
   • Upgrading to BizTalk Server 2006
   • Migrating Artifacts from a Previous Version of BizTalk Server
   • Blog: Upgrade to BizTalk 2006

External ComponentsGAC Build Events

External Strong Name Keys
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:

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.

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:



BizTalk Migration Links

BizTalk 2006, Enterprise Library, NUnit

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.

WF, Windows Workflow Foundation, K2.Net, MOSS, Microsoft Office SharePoint Server 2007