BizTalk 2004 and .NET 2.0

Published on : May 8, 2007

Category : BizTalk Server



Under which version of .NET Framework my code is going to run? I came across this interesting question in BizTalk newsgroup, “I am just wondering though how my local computer knows which CLR to load for the BizTalk Server 2004 Orchestrations when there is no entry in the BTSNTSvc.exe.config file to specifically point to the .NET 1.1 Framework when .NET 1.1 and 2.0 Frameworks are loaded to my computer. “. Here is my explanation: Applications that do not carry a configuration file or at least the supportedRuntime element in their configuration files (unconfigured applications) execute with the version of the framework that was used to build the application, provided that version of the Framework is installed on the local system. The version of the Framework with which the application was built is contained in the header (MANIFEST) of the application (assembly). Executing the following line of code against  Microsoft.XLANGs.BizTalk.Engine.dll in a BizTalk 2004 environment will output the result as v1.1.4322. The same piece of code in BizTalk 2006 environment will output v2.0.50727. Console.WriteLine(System.Reflection.Assembly.LoadFile(@”C:Program Files Microsoft BizTalk Server 2006 Microsoft.XLANGs.BizTalk.Engine.dll”).ImageRuntimeVersion); There are two important things which drives what version of framework will be used at runtime : 1. When the expected version of the Framework is not available, the CLR uses a later version of the Framework in its place. In other words, an unconfigured assembly built with Framework 1.1 executes with 1.1 on a system that has both 1.1 and 2.0 installed. That same assembly executes with the 2.0 Framework on a system with only the 2.0 Framework installed. 2. When it comes to interop scenarios the default behavior of CLR is to load the latest framework. This is because unless the managed assemblies, unmanaged assemblies lack the information in their header that describes the version of the framework (as we seen with the code snippet earlier) the code in question was build with; this leaves the CLR with no choice other than to load the latest available version of the framework. Some of the assemblies used by BizTalk (both 2004 and 2006) runtime components falls under the second category (interop assemblies), which leaves CLR to load the latest available framework.  If you need to override these default behavior, you can set the supportedRuntime/requiredRunTime in the .config file (BtsNtSvc.exe.config for In-Process host and corresponding IIS config file based on version 5.0 or 6.0 either dllhost.exe.config or w3wp.exe.config for isolated host)  for the process as shown below, which forces to use .NET framework 1.1. <configuration> … <startup> <supportedRuntime version=”v1.1.4322″ /> </startup> … </configuration> Ultimately, this means all managed components called by a particular application (BizTalk 2004) runs on the same version of the Framework. New Assembly, Old .NET It’s advisable to build your custom assemblies against the same version of .NET that you will be running them against. i.e .NET 1.1 for BizTalk 2004 and .NET 2.0 for BizTalk 2006. That way you’ll have correct references and avoid surprises from behavior difference between builds. Custom components that are written to use the .NET Framework 2.0 will not work in BizTalk Server 2004. These components include adaptors, pipeline components, functoids, and user code that may be referenced from orchestration or rules policies. This is because new assemblies cannot be opened on older CLR, just because they don’t understand them, and the runtime will throw BadImageFormatException. References: Nandri! Saravana