In a BizTalk 2006r2 solution, we encountered a build issue with BizTalk where a map that referenced a particular schema was causing BizTalk to fail to build. The symptom was that Visual Studio would continually build until it ran out of memory. The cause of the issue was tracked down to a particular service that was generated from the Entity Framework and contained inter-referencing classes. Normally this would not cause the issue but EF decorated the contracts in manner that confused the BizTalk build process only if the referenced schema was the source schema.
At the time, I found a workaround that I thought was clever…
In the map, I set the message type of the source schema to the XLANG Any message. This would build, and using custom xslt I could achieve what was required.
The upgrade of these maps from 2006r2 to 2009 did not display any issue. I did notice that a Schema referenced by Map has been deleted error would be displayed if the map was selected in a Receive Location’s Inbound or Outbound Map. The map would still work in BizTalk 2009.
After upgrading to BizTalk 2010, the Admin Console displays the message on the initial refresh of the BizTalk Group applications and no applications are displayed. I did find that if I restarted a host instance, the applications would then display in the console.
The error message in BizTalk 2009 is a annoying but would not affect functionality. The maps would work at runtime.
In BizTalk 2010, the maps still work at runtime but the issue in the Admin Console is more severe and prevents functionality from being run. For instance, if the library with the map is removed from resources, the error message is displayed and no action is applied. Once a map is deployed with the issue there is not a way to remove it (without hacking the databases).
The upgrade procedure was reviewed and the issue confirmed by a Microsoft consultant. The issue is being submitted to the product group to review.
Note: I did try to remove the group and re-connect.
Note: I did try to remove the library via powershell but the same issue was encountered:
Fri, Nov 12 2010 12:17 PM