Deploying a new version of an assembly involves multiple scenarios:

• File replacement
• Service pack
• Major application version deployment

File Replacement Scenario

Note  .NET Framework addresses this scenario with its own capabilities.

In the file replacement scenario, you discover a problem in a map contained within an assembly that you have deployed. You need to update the map in the solution. All your maps and schemas are in a single assembly. You repair the map defect, change the version number to 1.1 from 1.0 and rebuild the assembly. You do not rebuild any assemblies that depend on this assembly. You deploy your assembly and install it to the GAC. BizTalk Server includes full assembly name information for all references including the version number so its runtime behavior does not change.

To bring the new map into production, .NET Framework applies a policy file that causes all references of version 1.0 to go to version 1.1. This only changes the behavior of references for newly started host servers. To enable all new instances to use the new assembly, run each of the hosts one at a time to force the application domains to pick up the policy change. Service is not interrupted provided you configure more than one host server instance.

Note  You must reduce service interruption to transition to a new version or apply a file replacement.

Service Pack Scenario

In the service pack scenario, you deploy a large number of file replacements that are tricky to maintain; however your application is still compatible at the port and message level. You want to create a new baseline application for new deployments. You change the version number to 2.0 and rebuild the entire application or subsystem. You deploy al the assemblies and install them in the GAC. Next, you bind the application to the same bindings as the original application. You monitor the system for instances of version 1.0 using the Health and Activity Tracking (HAT) view. When you complete or terminate all the active, dehydrated and suspended instances, you can undeploy the version 1.0 application. At this point, you enlist and start the new application which goes into production.

Major Application Version Scenario

In the major application version scenario, you need to deploy a major new version of the application. It requires partners to change their interaction with the system due to either schema or protocol change - essentially a new application. The changeover to this system has been tested but not under the scale of a full production system. The IT administrators want to pilot the new system with 20% of the partners, and gradually increase that percentage until all the partners are using it.

The application is version 10.0 and you deploy it alongside the original application. All pipelines specify the set of schemas they can process using full names to avoid colliding with the existing schemas. You set up a new receive location to accept activation messages for the new version of the application. The application is bound, configured and activated. Use SEED to enable specific partners to re-route their requests to the new receive ports.

Note  To upgrade your assembly version, all applications bind to the exact version of the BizTalk items they use.

Note  You can resolve naming conflicts at the assembly or schema level without rebuilding the application.

Note  The solution still maintains the same receive location after you disable the old assembly version.

To implement changes to a BizTalk solution by upgrading an assembly version, perform the following steps:

1. Remove existing application and components.
2. Make the required changes to the project.
3. Change all version numbers of the assemblies in the application you have updated.

   Note  For information about version numbering, see Assembly Versioning in the .NET Framework help available from Microsoft Visual Studio .NET 2003 or online at http://go.microsoft.com/fwlink/?LinkID=21710.

   Note  When upgrading, you do not have to end long-running transactions when unenlisting BizTalk items before enlisting them in your new assembly version.

   Note  Use the Pipeline Designer and BizTalk Explorer Object Model to avoid schema collisions when upgrading assembly versions.

4. Rebuild the solution.
5. Deploy the new version.
6. Point the port to the pipeline again.

Note  Assembly deployment in BizTalk Server does not support .NET Policy Files. In certain circumstances, such as when dehydrated or suspended instances will be resumed, using policy files may lead to data loss and service failure.

The following diagram shows a typical deployment of a new version.

Developing Assemblies in the Development Environment

In the development environment, a developer completes the following tasks:

1. Edits necessary assemblies.
2. Changes all version numbers associated with application.
3. Re-builds the assembly.

Deploying Assemblies in the Target Environment

In the target environment, an IT administrator completes the following tasks:

• Removes the existing application and components using the Windows Add/Remove programs if you used the BTSInstaller utility to install your application with an MSI package
• Deploys the latest version of the assembly after a developer has rebuilt the assembly

Note  For all Business Activity Monitoring (BAM) information related to orchestrations, see Deploying BAM Definitions.

See Also

Schema Deployment

To download updated BizTalk Server 2004 Help from www.microsoft.com, go to http://go.microsoft.com/fwlink/?linkid=20616.

Copyright © 2004 Microsoft Corporation.
All rights reserved.