Updated .NET Framework Support

BizTalk Server 2010 supports building new applications only on .NET Framework version 4. You can build both BizTalk applications as well as custom applications (such as custom functoids, custom pipeline components) using .NET Framework 4. However, BizTalk Server 2010 continues to support the BizTalk Server 2006 R2 and BizTalk Server 2009 applications (BizTalk applications and custom applications) built on .NET Framework 3.5 SP2.

With support for .NET Framework 4 and improved integration with Visual Studio 2010, developers can now take advantage of BizTalk artifact property pages being integrated into Project Designer tabs, as well as migration with the Visual Studio Project Update Wizard.

Migrates the Existing Projects to BizTalk Server 2010

If you launch an existing BizTalk project in BizTalk Server 2010, it automatically gets migrated, changing the .NET Framework version to 4. You cannot modify the .NET version number later in the Properties dialog box of the BizTalk project.

When you attempt to open any of the existing BizTalk Server 2006 R2 or BizTalk Server 2009 projects in BizTalk Server 2010, the following warning message is displayed. Click OK to proceed with migration.

Warning message for migration

Also, you can silently migrate the existing BizTalk Server 2006 R2 or BizTalk Server 2009 projects to BizTalk Server 2010 using the Visual Studio 2010 command prompt.

To migrate the existing projects silently:

  1. Open the Visual Studio command prompt,

  2. Type the following command and press ENTER.

    Devenv <path of the sln/btsproj file> /upgrade
    The command launches the existing BizTalk project and migrates it to BizTalk Server 2010.

In .NET Framework 4, you can reuse the application DLLs which have been built for .NET Framework 3.5 SP2. You need not modify the DLLs and rebuild them for .NET Framework 4. When you migrate BizTalk applications from BizTalk Server 2006 R2 or BizTalk Server 2009 to BizTalk Server 2010, the application DLLs, such as schema DLLs and orchestration DLLs, automatically get upgraded for .NET Framework 4 at runtime.

Launches MMC from All Programs Only

In BizTalk Server 2010, you can launch the BizTalk Server Administration Console only from Start > All Programs > BizTalk Server 2010 > BizTalk Server Administration.

In BizTalk Server 2006 R2 or BizTalk Server 2009, you could launch BizTalk Server Administration Console also from <drive>:\Program Files\BizTalk Server <version>\btsmmc.msc. This is not available in BizTalk Server 2010 any more.

No Access to BAM Interceptors

In BizTalk Server 2010, the Windows Workflow Foundation (WF) interceptor will not work with the new WF engine in .NET Framework 4. The WF interceptor will continue to work in .NET Framework 3.5 SP2.

The Windows Communication Foundation (WCF) interceptor works with the new WF engine in .NET Framework 4.

For conceptual information about BAM WF and WCF, see What Are the BAM WCF and WF Interceptors?

.NET 4.0 Custom Application Scenarios

If your custom application is built with the .NET Framework 4 but has a dependency on a mixed-mode assembly built with an earlier version of the .NET Framework that uses .NET CLR version 2.0 you must use the useLegacyV2RuntimeActivationPolicy attribute in your configuration file.This is because all the managed code components in BizTalk Server 2010 run on CLR 4.0. As these components are compiled against .NET Framework 4, they need a config file to run in CLR 4.0. Listed below are a few common scenarios:

  • While using isolated adapters (using .NET Framework 4), you must set the useLegacyV2RuntimeActivationPolicy to True. If useLegacyV2RuntimeActivationPolicy is not used, BizTalk dlls get loaded with CLR 2.0 in the isolated adapter host process. If you have resources in a dll that is GAC’ed in 4.0 GAC and is being used by a BizTalk dll (for example, an XML receive pipeline), it fails. Since the BizTalk dll was loaded in CLR 2.0, the lookup cannot happen in 4.0 GAC.

  • If you hit the InvalidCastException when using a custom-based .NET Framework 4 application, set the useLegacyV2RuntimeActivationPolicy value to true and the supported runtime version to v4.0. In these scenarios, set the attribute to true.Setting the attribute to true prevents CLR version 1.1 or CLR version 2.0 from loading into the same process, effectively disabling the in-process side-by-side feature.

    The useLegacyV2RuntimeActivationPolicy=true attribute is required to call .NET Framework 4.0 assemblies. Therefore, even if an application is directly targeting the .NET Framework 4.0, you must still create a configuration file that contains this attribute.

See Also

© 2010 Microsoft Corporation. All rights reserved.

Community Additions