BizTalk Map Bug Causes Inconsistent Results
I found what I would call a bug with the BizTalk Mapper (does anyone dare call it a feature?). Let me show a simple version of the problem I encountered:
I created a BizTalk project that contains a map that calls an external assembly (in my case part of the same solution), such as:
My external assembly is version 18.104.22.168, compiled in Development mode, and it looks like this:
public class Helper
public string ReturnVersion(string ignore)
I deployed the map and the assembly. I tested the map. Sure enough, “22.214.171.124″ is mapped to “SomethingElse”. No surprises yet.
I then changed the ReturnVersion function to return “126.96.36.199″. Similarly, I incremented the version of the external assembly and BizTalk project and compiled in Release mode (let’s pretend I’m done with development and I’m now ready to release). I double checked the references in the Solution Explorer – sure enough Blog.ShowMapBug.Utilities shows the new version as the reference.
I deployed the solution and GAC’d the assembly. I updated my send port to use the new map. I restarted the Host Instance. I then tested things out. What would you expect to get mapped to SomethingElse? 188.8.131.52, right? Well it doesn’t work. 184.108.40.206 still shows up. Why?
If I open the BizTalk map in an XML editor and search for the assembly, I find:
<Script Language=”ExternalAssembly” Assembly=”Blog.ShowMapBug.Utilities, Version=220.127.116.11, Culture=neutral, PublicKeyToken=e767c75a9f3ac928″ Function=”ReturnVersion” AssemblyPath=”..\Blog.ShowMapBug.Utilities\obj\Debug\Blog.ShowMapBug.Utilities.dll” />
So, you’re now thinking what I thought. Okay, just update the Version number there, right? Nope. It turns out that the version number here gets ignored altogether and “18.104.22.168″ will continue to get mapped to “SomethingElse” (using the old assembly).
So what’s going on? It turns out that the problem is the AssemblyPath reference. It’s pointing at the “Debug” version of the external assembly. Once deployed, you’d THINK this wouldn’t be a problem, but it is. The only way to fix this problem is to point the DLL at the Release mode version of the file, i.e. AssemblyPath=”..\Blog.ShowMapBug.Utilities\obj\Release\Blog.ShowMapBug.Utilities.dll.
Amazing, isn’t it? Of course in this simple scenario it wasn’t too hard to follow. But of course real maps, real external assemblies and real projects are much more complex, and it took me a few hours to figure out why in the world the project wasn’t behaving as it was expected to.