CRM 4 adapter works with BizTalk 2010

A couple months back I did a test for a client about whether the legacy Dynamics CRM 4 adapter would work successfully on BizTalk 2010. I know this is not the recommended configuration and that the CRM 2011 SDK does not mention this as an acceptable or supportable configuration. Many companies have made a significant investment in CRM 4 and may not be able to upgrade their CRM software. So I am just putting this information out there in case you are wondering.

Others have reported needing to use a registry workaround for getting the adapter to install for BizTalk 2009: I followed this workaround with BizTalk 2010 on Windows Server 2008 R2 and it worked fine. The CRM 4 adapter install worked fine. I was also able to run the schema creation wizard in VS 2010.

I did not try running the software in this configuration in a production environment and have not tested this configuration completely. But usually in my experience if the install works fine and the designers still work in VS then you can probably work with this configuration, if only for a temporary workaround while you create a migration strategy.


Using SharePoint Online for InfoPath Forms Services


Today I thought it would be fun to do more research on what InfoPath looks like in the cloud. There had been a few hints about Forms Services running on SharePoint Online and some people were suggesting that it would only work once Office365 came out. Today I started a BPOS trial at and created a forms library to test out my strategies on InfoPath.

To give away the spoiler, I got it to work successfully. Apparently this is currently an unsupported feature (I think until Office365 comes out), but it does work. Here are the steps that I did to test this out. In a recent post I talked about how the license changes to MOSS 2010 no longer provide forms services as a feature when you use the standard CAL. But BPOS is relatively inexpensive so I think it provides a cost-effective replacement for the MOSS functionality. I found the documentation a little lacking on how to do this so I thought I would put together a walkthrough of how I got it to work.


1. So the first thing I did was make a sample form in InfoPath:

2. Then I save it and go to Tools\Form Options to enable it to work in a browser:

3. Then I just have to go through a couple pages of the wizard to publish to a Microsoft Online site.

You have to authenticate with SharePoint Online at this point. Then the next page

Then choose the forms library from your SharePoint Online site that you want to publish the form for. In the following screenshot I show a couple forms libraries. I actually used a different form library for the later pages of this wizard called OnlineFormsLibrary.


Then you get a page that says the form was published successfully:

4. Then I wanted to show the form from my browser even though I had InfoPath installed. On the form library settings you can specify that you want the form to display as a web page which will show the forms services rendering that does not require InfoPath. Here is the form for specifying this:

5. Then you can view the form by making a new item in the forms library. Here is an example of my form being rendered through Forms Services:


So Forms Services does work with SharePoint Online, even with just a BPOS trial. This is exciting news. As far as I know, BizTalk cannot currently integrate with SharePoint Online for document library functionality because the WSS adapter web service does not exist in the cloud. The next thing I will try is being able to post the results from InfoPath back into a custom WCF service in the cloud. From there the data could be sent back into an on-premise hosted BizTalk server via the service bus. This whole integration feels like sending something from outer space back to earth but I feel good just knowing that at least it is possible. 🙂

Why would you want a WCF LOB SDK Adapter?


In my last post I mentioned the registry content for registering a custom WCF LOB SDK binding as an adapter. I am still working out the details of how this should be done for a custom adapter and will be hoping how to do this in a walkthrough in a later post. 

To give you some preview of the process, the adapter class just needs to inherit from Microsoft.Adapters.Common.BizTalk from the BizTalk adapter pack rather than Microsoft.ServiceModel.Channels.Common.Adapter from the WCF LOB SDK. The abstract classes for Microsoft.Adapters.Common.BizTalk are included with the BizTalk Adapter Pack. The GUID values mentioned in the .reg file are set in the derived adapter classes and when calling the base class constructor for the adapter, WcfBtsAsdkAdapterBinding.

While it looks like it is possible to register a custom WCF LOB SDK binding as an adapter, the question comes up as to why would you ever want to do this when you can just use the custom binding in the WCF-Custom adapter anyway. This is one question I have asked repeatedly in reference to why the BizTalk adapter pack gives the developer the option of using the separate adapter rather than the bindings with the WCF-Custom adapter. At this time I am not sure if some of the scenarios I have come up with explain why the BizTalk adapter pack bindings are also exposed as custom adapters.

I wanted to take this post and describe a few scenarios that would be useful for having the capability of an adapter rather than a WCF-Custom binding.


Deciding whether to expose a WCF LOB SDK binding vs. a full adapter is an important question that depends largely on the consumers of your data. If you want the same data and management of the connection to your data to be the same whether it is being called from .NET or BizTalk then use of the standard custom binding makes sense. You will only need to code the logic once as the custom binding. But there are typically many differences between .NET applications and BizTalk applications so it seems like there would be compelling reasons to have other settings or different settings based on whether the binding is being called from a BizTalk system. For example, SSO settings like the SSO Application Name and key should not be exposed unless the binding is being called from BizTalk. These properties will not make sense if you are providing a way to connect to your custom LOB data without going through BizTalk.

The full adapter does have a configuration limitation that prevents it from fully functioning as an equivalent to the WCF-Custom binding. The custom binding configuration exposes the custom behavior config window for all WCF-Custom adapter handler properties. At this point I am not sure if it is possible to have the custom full adapter to provide a customized property page for the adapter handler properties. Interestingly, all of the BizTalk adapter pack custom adapters have the properties button grayed out in the adapter handler window.  So it is not even possible to choose the same adapter handler configuration as found on the WCF-Custom adapter handlers so if you did use a full adapter rather than WCF-Custom you would still need to register the custom WCF behaviors in the machine.config. This could possibly be an overlooked scenario in the current implementation.

So theoretically it is possible to come up with a reasonably good scenario for splitting apart the properties and implementation based on the caller type. But due to the current BizTalk admin console limitation on the adapter handlers configuration, there may unfortunately be some tradeoffs.


Sample .reg file for WCF-LOB SDK Adapter registration

On the forums today someone was asking how to register a custom adapter based on the WCF LOB SDK. The question was not how to get it to show up in the bindings list for the WCF-Custom adapter, it was how to get the custom adapter to show up as an actual adapter. With the BizTalk adapter pack, the custom adapters show up both as custom bindings under the WCF-Custom adapter and as custom adapters under Platform Settings\Adapters. The WCF LOB SDK gives good examples for how to register the custom binding and there are some free tools to help with this like this one: But there are not any .reg files in the samples folder for the SDK like there are for the samples found at c:\Program Files (x86)\Microsoft BizTalk Server 2010\SDK\Samples\Adapter Development\…

I developed one custom adapter using the older adapter framework for a major client to interface with the Endeca search index tool ( Based on my experience working with the adapter framework, I knew there was probably a GUID value I could use to find the registry settings for registering a WCF LOB SDK adapter. So I opened the WCF-SQL adapter assembly in Reflector and found the GUID value. Then I opened the registry and searched it under HKLM\Software\Microsoft to find the registry keys for the WCF-SQL adapter. Although this was not surprising to me, it was interesting to see that many of the registry values are similar to the values given for the adapter framework settings in the .reg files of the SDK samples.

Here is the WCF-SQL adapter registry content – shown below. Here is a link for just downloading the .reg file. This seemed like a missing sample file so I will be working on taking the Contoso and Echo adapters and creating registry files for them. There are a couple logical questions about what to do to your custom WCF LOB SDK code in order to make it work with the .reg file so I will be working on that next. Having the .reg file available makes it a lot easier to accomplish the adapter registration.


Windows Registry Editor Version 5.00


"AdapterMgmtTypeName"="Microsoft.Adapters.Sql.BizTalk.WcfBtsSqlManage, Microsoft.Adapters.Sql.BizTalk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"InboundTypeName"="Microsoft.Adapters.Sql.BizTalk.WcfBtsSqlReceiver, Microsoft.Adapters.Sql.BizTalk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"OutboundTypeName"="Microsoft.Adapters.Sql.BizTalk.WcfBtsSqlTransmitter, Microsoft.Adapters.Sql.BizTalk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"AliasesXML"="<AdapterAliasList />"
"ReceiveHandlerPropertiesXML"="<CustomProps><WcfExtensions vt=\"8\" /></CustomProps>"
"ReceiveLocationPropertiesXML"="<CustomProps><Headers vt=\"8\" /><BindingType vt=\"8\" /><BindingConfiguration vt=\"8\" /><ReferencedBindings vt=\"8\" /><ServiceBehaviorConfiguration vt=\"8\" /><EndpointBehaviorConfiguration vt=\"8\" /><InboundBodyLocation vt=\"8\" /><InboundBodyPathExpression vt=\"8\" /><InboundNodeEncoding vt=\"8\" /><OutboundBodyLocation vt=\"8\" /><OutboundXmlTemplate vt=\"8\" /><DisableLocationOnFailure vt=\"11\" /><SuspendMessageOnFailure vt=\"11\" /><IncludeExceptionDetailInFaults vt=\"11\" /><CredentialType vt=\"8\" /><UserName vt=\"8\" /><Password vt=\"8\">Encrypted</Password><AffiliateApplicationName vt=\"8\" /><OrderedProcessing vt=\"11\" /><Identity vt=\"8\" /></CustomProps>"
"SendHandlerPropertiesXML"="<CustomProps><WcfExtensions vt=\"8\" /></CustomProps>"
"SendLocationPropertiesXML"="<CustomProps><Headers vt=\"8\" /><BindingType vt=\"8\" /><BindingConfiguration vt=\"8\" /><ReferencedBindings vt=\"8\" /><EndpointBehaviorConfiguration vt=\"8\" /><StaticAction vt=\"8\" /><UseSSO vt=\"11\" /><UserName vt=\"8\" /><Password vt=\"8\">Encrypted</Password><AffiliateApplicationName vt=\"8\" /><ProxyAddress vt=\"8\" /><ProxyUserName vt=\"8\" /><ProxyPassword vt=\"8\">Encrypted</ProxyPassword><InboundBodyLocation vt=\"8\" /><InboundBodyPathExpression vt=\"8\" /><InboundNodeEncoding vt=\"8\" /><OutboundBodyLocation vt=\"8\" /><OutboundXmlTemplate vt=\"8\" /><PropagateFaultMessage vt=\"11\" /><EnableTransaction vt=\"11\" /><IsolationLevel vt=\"8\" /><Identity vt=\"8\" /></CustomProps>"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{59b35d03-6a06-4734-a249-ef561254ecf7}\Implemented Categories]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{59b35d03-6a06-4734-a249-ef561254ecf7}\Implemented Categories\{7F46FC3E-3C2C-405B-A47F-8D17942BA8F9}]

"Assembly"="Microsoft.Adapters.Sql.BizTalk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"DateTime"="12/28/2010 00:20:47"

Trying to Rehost the BizTalk Mapper Activity (AppFabric Connect)


Recently I was working on a technical question and proof of concept about being able to reuse the BizTalk mapping designer functionality. The goal was to be able to reuse the functionality within a business user application to enable an information worker to create a map. One of my personal goals was to try to do this in an environment that did not incorporate Visual Studio. This is challenging because until recently with BizTalk 2010 there was not really any way (that I know of) to export or hijack the BizTalk extensions from Visual Studio and reuse them in a separate non development environment.

With the BizTalk 2010 beta it has been possible to develop message transforms within the VS 2010 workflow projects once you install the WCF LOB SDK beta. A Windows workflow (WF) activity known as the BizTalk mapper activity shows up in the VS toolbox. A few other articles exist on using this activity, see the following for a good summary:

I decided that it would be interesting to know whether or not you could work with this activity within a WF rehosted environment because this would provide the ability to reuse the mapper functionality in a partial trust, non VS environment. A WF rehosted environment provides a lighter-weight visual editing environment for a workflow that is either stopped or running.

This post shows what I encountered when trying to rehost and manipulate a workflow that use the BizTalk mapper. Unfortunately I found that in the current beta it is not possible to easily manipulate the BizTalk mapper activity in a rehosted workflow. Upon further investigation, the API for the mapper depends on the presence of Visual Studio and simply compiling a project that references the mapper toolbox activity requires extensive Visual studio references. Hopefully this post will save you some time from trying to do this yourself.



To start out with a good basis for the test, I found a blog post which provided a good WF 4 rehost sample. I chose the one at Thanks to Maurice for this great WF 4 post. Basically this enables you to open an Activity.xaml file for a coded workflow and then view it in the rehost environment with the toolbars at the left like in VS. To add the BizTalk mapper activity I did the following steps:

1. Directly referenced the assemblies relating to the BizTalk Mapper activity. Below I give a little more detail on these:

There are a couple of assemblies related to the beta version of the BizTalk mapper activity, but all of them install into “C:Program Files (x86)Microsoft BizTalk Server 2010Developer Tools” (on a 64-bit system) rather than the typical WCF LOB SDK path of “C:Program FilesWCF LOB Adapter SDKBin”.
  • Microsoft.ServiceModel.Channels.MapGenerator – Creates the cs or vb code for the code behind of the map.
  • Microsoft.ServiceModel.Channels.MapperActivity – WF 4 activity classes, and also includes the type selector form pop up form that generates the BizTalk schemas and default maps.
  • Microsoft.ServiceModel.Channels.MapperToolboxItem – additional packaging that basically wraps the MapperActivity but relies extensively on the VS packaging assemblies.

2. Then I started trying to build the project for the new references because I want to try to manipulate a workflow with the mapper activity already added in and/or add it to a new workflow. To help with this I opened the three assemblies above in Reflector to look at the references. Quickly we see that the MapperActivity assembly does itself rely on Microsoft.VisualStudio.Shell.Interop (v. 7.1 so this is VS 2003) as well as the BizTalk mapper compiler.

If you keep all three of the assemblies from #1 referenced then you have to also reference a couple of other VS assemblies commonly used with VS extensions (obviously the MapperActivity was not meant for use outside of VS):

  • Microsoft.VisualStudio.OLE.Interop
  • Microsoft.VisualStudio.Shell.10.0
  • Microsoft.VisualStudio.Shell.Interop.10.0
  • Microsoft.VisualStudio.Shell.Interop.9.0
  • Microsoft.VisualStudio.Shell.Interop.8.0
  • Microsoft.VisualStudio.Shell.Interop (v. 7.1)
  • System.Drawing (for basic ComponentModel extensibility)

Basically to illustrate some of these dependencies, here are the first and third assemblies in reflector with references shown:

Then here is the second one for the MapperActivity:

You can also see that the MapperActivity relies on EnvDTE (related to VS) and also ole32.dll (unmanaged code).

3. Also add reference to Microsoft.XLANGs.BaseTypes.dll for handling the BizTalk type system and some other essentials.

4. Add code for adding the Mapper activity to the constructed toolbox:

// Add the BizTalk mapper
var bizTalkcat = new ToolboxCategory(“BizTalk Activity”);
var assembliesBTS = new List();


var queryMapper = from asm in assembliesBTS
from type in asm.GetTypes()
where type.IsPublic &&
!type.IsNested &&
&& type.ContainsGenericParameters    // Only matches the Mapper activity
select new ToolboxItemWrapper(type.FullName, type.Assembly.FullName, null, “MapperActivity”);

queryMapper.ToList().ForEach(ti => bizTalkcat.Add(ti));



So after configuring the WF 4 rehost to handle managing the BizTalk mapper activity, the activity shows up in the toolbox and can be added to the workflow editing screen but cannot be effectively managed and configured. Here is a screenshot of the running host with the BizTalk activity and a workflow rehost showing the mapper activity:This is great until you try to configure the BizTalkMapClass via the Edit button on the designer surface or via the property grid and you get an error that the project cannot be found as shown below:

This is because the Mapper activity relies on the EnvDTE project that does not exist outside of VS. I will attempt to do some other workarounds for managing the mapper activity outside of VS but for now it looks like the mapper is restricted to use within VS. I welcome all comments on other approaches to making this work. Also, the code for my attempts so far may be found here: Ben’s SkyDrive public folder


BizTalk 2009 Incompatible with SQL 2008 R2

After responding to a few community threads about BizTalk 2009 compatibility on W2K8 R2 and SQL 2008 R2, I decided to try an install with BizTalk 2009 and SQL 2008 R2 to see if I noticed any incompatibilities. I had not tried this combination before so I decided it was worth a few hours
of time to determine how well it worked.
I have already confirmed that BizTalk 2009 works fine on W2K8 R2 although this is not an officially supported configuration. On one of my client’s projects this is the environment configuration and it is running quite well. But on this specific project we are running SQL 2008 [R1]. Next are the steps I took to install everything.
If you have any questions about installing this configuration I recommend the BizTalk 2009 install guide. Most of the screenshots for SQL 2008 R1 look the same as for SQL 2008 R2.
Installation Steps
1. Used a W2K3 R2 SP2 base image to start out with. SQL 2008 R2 supports W2K3 so this was acceptable.
2. Installed SQL 2008 R2 November CTP. Since I had a copy of this version I used it although SQL 2008 R2 RTM was released to MSDN subscribers recently about a week ago (5/3/2010). I followed the directions at which gives directions for the November CTP. 
  – I chose to uncheck SQL Replication, Fulltext indexing, and SQL Server Books Online.
3. Installed VS 2008
  – I chose to uncheck VB.NET, C++, and SQL Express.
4. Installed BizTalk 2009.
5. Configured BizTalk 2009.
When configuring BizTalk, it failed on the Group with the error:
Failed to create Management database “BizTalkMgmtDb” on server “BENC-NEWBASE”.
Error “0x80040E1D” occurred.
To try to get around the error, I tried the following things but was not successful:
– Enable TCP/IP, named pipes in SQL Configuration Manager.
I think the root of this problem is that the code used to create the BizTalkMgmtDb may be used a data type no longer supported in SQL 2008 R2.
Apparently SQL 2008 R2 is both not supported and not compatible with BizTalk 2009. This was a big surprise for me. After doing some digging I did find this post about compatibility: It is hard to find because the naming is not full – I do not call it BizTalk 09 or Sql R2.
We will have to wait for BizTalk 2010 for SQL 2008 R2 support.

How to Abort a Commerce Server Catalog Import

While working on a Commerce Server/BizTalk project I have encountered a workaround for when you are running a Commerce Server replace import. From BizTalk server we would kick off a large import of Commerce Server catalog records and occasionally need to run these in replace mode. Replace mode handles reorganizing the underlying data structures of the Commerce Server catalog. Incremental mode merely updates the data with supplemental information. These modes are documented here:
We have found that replace mode runs quite a bit slower than incremental so we usually just run incremental. When the Commerce Server catalog columns or design changes we need to run a replace. A significant issue with the Commerce Server catalog adapter is that it does not allow you to do concurrent import execution for the same Commerce Server site. So usually if you start up a replace you wind up waiting for it to complete. Even if the BizTalk process stops, the Commerce Server process continues and keeps blocking subsequent imports. I had not been able to find any other way to abort an import except these steps:
If you want to force a stop of a Commerce Server import, do the following steps:
  • Stop the SQL Server instance hosting the Commerce Server catalog database
  • Run iisreset to refresh the process hosting the Commerce Server catalog web service.


Configuring BAM Tools on W2K8 R2


To continue my tradition of trying BizTalk in unsupported (or not fully supported) environments, I have been working with BizTalk 2009 on Windows Server 2008 R2 on 64-bit. This OS is being used at my current client and I have been able to configure everything in BizTalk to work except for the BAM Tools / BAM Alerts functionality.

I had posted on setting up BAM with SQL 2008 a few months ago and once the 4 hotfixes were released, I was able to get everything working on a single machine after applying the hotfixes and reconfiguring BizTalk. The current release of the BizTalk install/setup guides only go so far as supporting W2K8 R1 but do not officially announce support for R2. This is due to the way the dates lined up around the BizTalk 2009 release, but I always wonder if there are any issues, especially breaking ones.

This post walks you through a hurdle I encountered configuring BAM Tools in a multi-server environment.

System Configuration

Here is the configuration I am trying now:

  • W2K8 R2
  • SQL 2008 on separate server
  • VS 2008 w/ SP1
  • 4 Hotfixes for Notification Services, etc. (64-bit version)
  • BizTalk 2009

Configuration Issues

After applying the 4 hotfixes I try to configure BAM Tools. I am getting the following error:

Microsoft SQL Server 2008 Data Transformation Services (DTS) for BAM Archiving is not installed on the local machine.  Please install Microsoft SQL Server 2008 Integration Services. (Microsoft.BizTalk.Bam.CfgExtHelper.ToolsHelper)
Could not load file or assembly ‘Microsoft.SqlServer.ManagedDTS, Version=, Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified. (Microsoft.BizTalk.Bam.CfgExtHelper)

This error looks similar to the one I had back on October 30, 2008 in this post:!62E68922E47BC425!400.entry. With the changes to SQL 2008, the workstation tools were moved into a different package component known as the Management Tools. The similar error was resolved with SQL 2005 by installing the Workstation Tools on the BizTalk server. I was able to resolve the above error by checking the Management Tools (Basic & Complete) SQL 2008 features as shown in the screenshot:


As software products change, their names and subsystems also change. But the documentation for the products usually changes slower so there is often a small gap to watch out for. I found one when configuring BAM Tools for BizTalk 2009 with SQL 2008 on Windows Server 2008 R2. This post can also serve as some of the scant evidence that BizTalk 2009 runs successully on Windows Server 2008 R2, but the issue described above might be one of the supportability gaps.


BizTalk 2009 on Visual Studio 2010 Beta 2

If you saw my posts a few months ago, I was testing BizTalk 2009 compatibility with VS 2010. My earlier posts found that the BizTalk extensions would only load in VS 2008 and not in VS 2010. In this post, I do a refresh of the install experience and give some preview of the .NET 4 features showing up in BizTalk 2009. The same conclusion about compatibility is reached here: the BizTalk 2009 extensions do not work with VS 2010. There is a new workarounds for getting a VS 2008/VS 2010 environment for working with BizTalk 2009.
Application Install Order
  • Use a clean VPC image
  • Setup pre-requisites: W2K8, SQL 2008
  • Install VS 2010 Beta 2
  • Install VS 2008, and VS 2008 SP1
  • Install BizTalk 2009

BizTalk Configuration

Then when configuring BizTalk on the first step for Enterprise Single Sign-On I get an error similar to this (cannot remember exact wording sorry):
Cannot connect to SSODB (Win32)
I found this blog post about re-regasm-ing the SSOSQL assembly: This helped me get around the error when configuring SSO. It is interesting that the problem occurs when VS 2010 is install prior to or after BizTalk 2009. I was then able to go through the BizTalk configuration wizard successfully. I was able to create BizTalk projects in VS 2008 fine. I did open the VS 2010 extensions manager and check for the BizTalk extensions but they are not showing up there.
There are quite a few valuable improvements with WCF 4 such as WS Discovery support, routing, and additional changes to Windows Workflow. All of these will have an impact on the Connected System landscape. Enjoy!

BizTalk 2009 on Dev 10 Part 2

I was able to play with BizTalk 2009 Beta on Dev 10 a little more and had some advice. When I installed earlier, I had not seen that the Developer Tools and SDK was grayed out and this was the reason the .btproj extension had not been installed properly. I eventually realized that on the VS 2010 CTP VPC, VS 2008 BIDS did not have VS 2008 SP1 so this was required to get the BizTalk 2009 Beta VS extensions to install at all.

With the VS extensions for BizTalk installed correctly, I was still not able to open BizTalk 2009 projects using VS 2010. For some reason the VS extensions are just not being applied to VS 2010.

Here is my updated install order to get BizTalk to work with as much as possible:

  • Setup the VS 2010 CTP VPC using the RAR downloads
  • Remove the expiration using the VMC file configuration
  • Remove VS 2008 BIDS – an upgrade will not install properly
  • Install VS 2008 Full
  • Install VS 2008 SP1
  • Install BizTalk 2009 Beta or latest version available
  • Configure BizTalk 2009
  • Install Team Explorer for VS 2008 – Be careful – Team Explorer does not work with VS 2008 and VS 2010 open at the same time.
  • Team explorer for VS 2008 did connect fine to the TFS 2010 server though.So I still wanted to answer a few questions. I was able to add a BizTalk 2009 project to TFS 2010 through VS 2008 w/ Team Explorer 2008 and view the source code in VS 2010, I was just not able to open the BizTalk projects. Here is a screenshot from VS 2010 with the BizTalk files in source control in TFS 2010:

    So this is good because it means it is possible to upgrade to TFS 2010 without affecting BizTalk solutions. VS 2008 will just need to remain in order to keep editing BizTalk 2009 projects.

    The other question I had was whether a BizTalk 2009 project can reference a .NET 4.0 assembly. VS 2008 SP1 cannot create .NET 4.0 versioned projects, so the reference would have to be a GAC or file reference rather than a project reference. I created a .NET 4.0 assembly from VS 2010 and referenced some v4.0.11 assemblies and recompiled. Then I tried referencing the assembly in my BizTalk project in VS 2008. It looks like it is possible to reference a .NET 4 assembly from VS 2008 for a BizTalk project but I was unable to build it successfully. Here is the message I got when adding the reference:

    After trying to compile I realized it was not possible to reference a .NET 4 assembly from Visual Studio 2008 SP1 (yet). I also tried referencing an M project using the latest Oslo January CTP SDK and was not able to successfully.

    So the good news is that you can migrate your TFS investment ahead of BizTalk and the BizTalk files will still check-in and import successfully. My next task will be to see how well the new ALM features of BizTalk 2009 translate over to working on TFS 2010.


    Blog at

    Up ↑