Known Issues with Updating Applications and Artifacts

Updating an Application

Removing or deleting an artifact does not remove it from all locations

Removing or deleting an artifact deletes it from the BizTalk Server databases, so that it no longer appears in the administration console or in the list of artifacts for an application generated by the BTSTask ListApp command. It does not remove the artifact from the Windows registry, the global assembly cache (GAC), a virtual directory, or the file system, if it exists in any of these locations. In the case of send ports, send port groups, receive ports, and receive locations, which exist only in the BizTalk Management database, this operation deletes the artifact entirely.

Updating an Artifact

Removing or changing the state of an artifact can cause an application not to work

When you add a reference from one application to another and make any changes to the state of an artifact on which another application depends, or you remove the artifact, the application that has the dependency will not function correctly. For more information about changing the state of an artifact, see the section on the appropriate artifact in Managing Artifacts (https://go.microsoft.com/fwlink/?LinkID=154725).

.NET policy files are not supported

The use of .NET policy files is not supported in BizTalk Server. This is because a policy file may not work as expected. Policy files redirect .NET to a specified assembly version in the GAC, but BizTalk Server often accesses assemblies and artifact data from a cache or the BizTalk Management database. Depending on the artifact type, caching situation, and whether host instances are restarted, the policy file may not do what is desired.

Updating an Assembly

Changes to an assembly may not take effect if the host is not stopped

BizTalk assemblies must follow .NET versioning rules. The main implication of this is that a BizTalk project, once built against a particular version of another .NET project or assembly (including BizTalk projects), continues to use that version until it has been rebuilt against a newer version.

A common problem occurs during development related to .NET versioning when the version numbers on a BizTalk project are not changed and the assembly is redeployed without stopping and starting the BizTalk host instance that the types are loaded into.

When the process is run again, the changes do not take effect. This is due to the way in which .NET assemblies are loaded into memory. Because the host already has an in-memory copy of the assembly, it does not reload the assembly when a new copy is put into the global assembly cache (GAC). For example, if version 1.0.0.0 of an assembly with an orchestration is deployed and running, and changes are made to the orchestration but the version number is not changed, then the changes do not take effect. After the host instance is stopped, the in-memory copy of the assembly is released and when the host instance starts again it reloads the new copy of the assembly and gets the changes. If a new version was deployed, for example version 2.0.0.0, and it was loaded, then the changes would take effect.

Changing the assembly version may break the relationship between an assembly and items that reference it by version

In .NET Framework development it is typical to update the assembly version number to the current build number when a build takes place. However, when developing a BizTalk solution, changing the assembly version number can break the relationship between an assembly and the dependent items that reference the DLL by its assembly version number. The following table lists items that refer to a BizTalk Server assembly by using its version number and the effect of changing an assembly version number.

Entity	Effect of changing assembly version number
Binding files	Changing the assembly version number causes any existing binding files that reference the assembly to fail. This is because the binding file references the assembly by attributes including its version number. You can update the version information in the binding file by using Notepad or another editor. You can also redeploy the solution and then regenerate the binding file by using the BizTalk Server Administration console. Finally, you can use scripts to automate deployment and versioning. For more information about deployment, see Deploying and Managing BizTalk Applications (https://go.microsoft.com/fwlink/?LinkID=154210).
BAM tracking profile definition (.btt) files	Changing the assembly version number causes any existing BAM tracking profile definition files to fail. The BAM tracking files are in a binary file format so they cannot be edited and instead must be regenerated. If BAM tracking profiles are required it may be necessary to do either of the following: - Avoid frequently updating version numbers during the build process - Delay building BAM tracking profiles until version numbers are stable
Web services published by using the Web Services Publishing Wizard	When the Web Services Publishing Wizard is used to produce an ASP.NET Web interface, the assembly version of the BizTalk Server assembly is included in the ASP.NET source code. The assembly version number is used at runtime by the ASP.NET interface as part of the bodyTypeAssemblyQualifiedName property of the Web service operation. If the version number of the BizTalk Server assembly changes without updating the bodyTypeAssemblyQualifiedName property, then subsequent Web service operations will be rejected by BizTalk Server. If the receive location uses the XmlDefaultPipeline, the subscription relies on the document type. It uses the embedded assembly information and will fail if the assembly does not exist. If you use the PassThruPipeline (which is the default if you expose a port and let the wizard create the receive location), the subscription ignores this embedded assembly information.