Infosys Microsoft Alliance and Solutions blog

« DST Impact on BizTalk Server | Main | ZTI of Vista over WAN »

BizTalk Business Rules Composer's Namespace issue

Recently on a project support we faced an issue in using the BizTalk Rules Engine. It so happened that the code was getting generated via some XSD files that were themselves based on some legacy code, which we had no control on.

This code generated, thus contained classes with similar names in different namespaces. The project configuration requirements, forced all these to be in a single assembly and when this assembly was loaded in Business Rules Composer application, it failed to recognize the different namespaces.

To explain further, take the following example (the code below doesn't do anything and is only for demostrating the issue)

namespace BRETest
{
    public class MyClass
    {
        public int MyMethod(string x)
        {
            return 0;
        }
    }
}

namespace BRETest.AnotherNamespace
{
    public class MyClass
    {
        public int MyMethod(string x)
        {
            return 0;
        }
    }

    public class TestClass
    {
        public int AnotherMethod(string s)
        {
            return 56;
        }
    }
}

namespace BRETest.YetAnotherNamespace
{
    public class MyClass
    {
        public int MyMethod(string x)
        {
            return 0;
        }
    }
}

When this code is compiled and deployed in GAC and via BRE Composer, I try to create a new Vocabulary of type .NET Class or Class member, and select the above created assembly, I can see MyClass listed three times in the Select Bindings dialog, but in the details in the lower part of this dialog, I see the namespaces as same for all three. The BRE Composer isn't able to distinguish the different namespaces.

Now, I won't call the above a very good design but we had some limitations due to which we weren't able to alter the code. A workaround would have been segregate the namespaces into different assemblies, but there were quite a few such classes and splitting all across assemblies also wasn't really a feasible option.

We raised this with Microsoft and they confirmed this to be a bug and provided us with the hot fix. Things are working fine post the hot fix. I will publish the link for the KB article on this blog once the KB is officially released by MS. 

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter