Solved: BizTalk Map Renaming Fails in Deployed Application

BizTalk map renaming isn’t quite as simple as renaming the map.

The Problem

I renamed a BizTalk map in VisualStudio’s Solution Explorer, compiled and deployed the application. However, in the BizTalk Management Console, the renamed map still shows up with its old name.

The Solution

This is one of those BizTalk things that we’ve all been caught out by at least once.
The solution is to right-click the map name in Solution Explorer and click properties. In the properties window, change the name of the Type to the name of the map. Then redeploy.
BizTalk Map Renaming

Solved: BizTalk Scripting Functoid Inline Script Issue

The Problem

I have been developing a rather complex map that includes various scripting functoids for manipulating dates.  One of the in-line C# scripts started producing output that simply didn’t make sense. I ran the code in LINQPad, and it produces the expected output, but testing the map resulted in some bizarre behaviour.

My code looked like this:

Given an input node that contains:


I expected:


But received:


The Solution

I validated the map, which generated the XSLT that is actually run on the input. I was surprised to find that the C# code embedded in the XSLT looked like this (notice the difference in the string formatting on the 6th line):

Why is this different from the code in the scripting functoid?

MSDN documents the answer:

Avoid using the same method signature more than once. When several Scripting functoids have the same method signature, BizTalk selects the first implementation and disregards the others.

It turned out that I’d created a similar functoid elsewhere in the map that uses the same method signature (name and parameters), but had the implementation above. It turns out that BizTalk recognized that more than one function was defined with the same name, and then silently ignored all but the first one.

Further Reading

BizTalk: Problem with Business Rules not Working

The Problem

If you’re having trouble getting Business Rules to work, remember that you can test your rules in the Business Rules Composer. Microsoft provides details on how to do so on MSDN.
However, I recently found that the business rules that I was testing were known to be correct (they worked on another machine) but were not being invoked on my PC.

The Solution

The reason that they were not working was because my PC was not configured correctly. I needed to add a new DWORD registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BusinessRules\3.0\StaticSupport = 1
Richard Seroter’s blog gives more details on the purpose of this key.

BizTalk: Problem starting file receive location

The Problem

I was having trouble getting a receive location started. Every time I attempted to start the receive location an error message was added to the event log and the receive location remained stopped. The error message was something like this:
The receive location "<PortName>" with URL "<FileLocation>" is shutting down. Details:"The Messaging Engine failed while notifying an adapter of its configuration. ".
The transport type of this receive location is FILE.

The Solution

I’ve encountered this several times before. The solution was to make sure that the <FileLocation> exists and that the security principle under which the receive location is running actually has permission to access the receive location. Once I did this, the receive location started first time.

Can't Open BizTalk Project in VS2008

If your VS2008 BizTalk developer machine looses its ability to open or create BizTalk Projects, the reason is probably that a registry key has been overwritten by an update or repair to Visual Studio. The resiltuion is to find the registry key and reset it to its correct value.
The registry key can be reset as follows:
For 32-bit versions of Visual Studio 2008, the registry key is:


For 64-bit versions of Visual Studio 2008:


Change the value from