“You are making my point!”

I was on a plane from Boston to Philadelphia earlier. “What better way to spend the time than flipping open my laptop and do some .NET programming!”, I thought. So I started to monkey around on some BizTalk code I have on my computer, and I come across this System.Collections.Specialized.HybridDictionary class in one of the sample SSO Configuration project. “Hmm, what the hell is this?” The documentation says it “implements IDictionary by using a System.Collections.Specialized.ListDictionary while the collection is small, and then switching to a System.Collection.Hashtable when the collection gets large”. Now that is an interesting object. Having nothing else to do, I broke out my favorite tool, .NET Reflector, to take a look at the internal implementation of this class. So here is the structure of this class in Reflector.

You can see that it includes two list-like class member variables: list (type of ListDictionary) and hashtable (type of Hashtable). They weren’t initialized in the constructor as you might guess though. They were in fact initialized in the public method of Add. What’s particularly interesting is that when the Add function is called the first time, the ListDictionary object is constructed to handle the object storage. However, when the number of the object in this list goes up to 10, it calls a ChangeOver private method. Hmm, I wonder what that method does?

Well, not surprisingly, this ChangeOver method construct a new Hashtable object, and then copy all the items in the DictionaryList object over to the Hashtable object. After that, it releases the reference to the DictionaryList object to let garbage collector clean it up.

The reason for this design is that a DictionaryList object is constructed as a linked list, whereas a Hashtable is constructed as an object array with hash keys stored together with individual items. With a smaller collection (the magic number is defined as 10 for whatever reason), a link list will give you better performance. When the collection grows larger, hash table usually perform better with the hash key lookup. I thought this was pretty neat. However, if you remove items from a DictionaryList object, it will not reverse the changeover process from an internal Hashtable object back to a DictionaryList.

Clearly I have too much time in my hands…

I was working on some BizTalk/SharePoint integration demo today when I discovered a bizarre bug in SharePoint. In your SharePoint server URL, if your server name carries underscore (”_”), yes underscore, your form services InfoPath form will not render! It will says some gibberish like “Session cookies must be enabled in your browser.”

Fortunately you don’t have to rename your computer (or in my case my VPC) to work around this problem. (I shudder at the thoughts of renaming my VPC and all the problems it might create to my other applications and servers). In SharePoint Central Administration site, in the Operations tab, there is a link named Alternate Access Mappings. All you have to do is to create a default public URL using a server name without the underscore sign. Of course you’d also have to go to your network administrator and ask for a new DNS entry of this new server name to map to this IP address. But it sure beats the hell out of renaming the computer. And in my case since I am doing all my demos on the VPC I didn’t even have to do that. I simply create a map to “localhost”. Problem solved.

I wonder if this bug is fixed in the SP1 of MOSS.

I recently wrote an article for the BizTalk Hotrod Magazine. (Hotrod is the only magazine out there exclusive dedicated to BizTalk developers. If you work with BizTalk, check it out. The best part? It is free!) It will be published on the 4^th issue which will come out later this month. The topic is about taking policies deployed in the BizTalk BRE, leveraging the BRE API as well as some magic WCF salt, turning it into a WCF service for any service client to consume. There are also some tips and tricks on xsd.exe. You can download the entire issue of BizTalk Hotrod here. (link coming soon). Meanwhile, you can also download the sample code here.

I was working on the EDI sample shipped with BizTalk 2006 R2 when I discovered a mysterious error. This is the “EDI Interface Developers Tutorial” located at “C:\Program Files\BizTalk Server 2006\SDK\” directory. The R2 Documentation also has a step-by-step description on this tutorial so it is really helpful for you to get a grasp on the EDI capabilities offered by R2. It also has an AS2 example with very detailed documentation as well.

Anyways, so I started playing with this EDI sample. After I deployed the sample application, and configured all the ports and parties, I ran into an exception while executing the application. Once I dropped my sample order message at the receive location, a 997 acknowledgement message was generated by BizTalk server, which is the correct behavior. However, the transformed order message never came out of the “toOrderSystem” send port. Upon closer examination in the event viewer (always the first place you should look when something is wrong), I found the following error:

This error really baffled me because I knew that my 850 schema was deployed and hence not missing. I also knew that the schema could not have been invalid since I took it straight from the SDK without any modification. So the only possibility, if we were to read the Error description to the letter (which is a rare excise for me anyways), is that I have a duplicated schema. (Of course it said Transaction set instead of schema, which obvious didn’t help.) So I went to my BizTalk Admin Console, and looked at the schema node of each deployed application. Lo and behold, I found a duplicate schema in a different application. Apparently I tried to work on this tutorial before and I have completely forgotten about it. After removing this duplicated schema my tutorial started working without a hitch!

Lessons learned:

1. Don’t create duplicated schemas in BizTalk. In fact, a better question should probably be, why does BizTalk allow developers to deploy schemas with the exact same namespace and root node name in the first place? Shouldn’t it be denied to save my trouble?
2. The best place to check the duplicates is actually in the “<All Artifacts>” application container. If you worked on BizTalk 2004 you should be familiar with this container since that was all you had. J Instead of going application by application, here you can check out all the artifacts registered with the BizTalk server administration database.