“You are making my point!”

LINQ to SQL and ADO.NET are both powerful data access mechanism now available in Visual Studio 2008. If you are confused by the these two methodologies and want to choose one over the other for the project you are working on, here is an excellent blog post to clarify the differences and similarities.

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…

If you ever have to deal with collations in SQL Server at the server level, database level, table level or down to column level, you know it is a pain in the you know what. Here is a pretty good article that helps to alleviate that pain.

I gave a talk on Open XML last Thursday at the NYC .NET User Group event, organized by Stephen Forte, Andrew Brust and Bill Zack. It was great fun speaking to a whole roomful of enthusiastic .NET developers and getting great feedback. This has been the best experience so far I have had with this talk. I hope I can do it again sometime with some new material.

Anyways, here are the slide deck and sample code for download. Enjoy…

Recently I have been working on a fairly large MOSS deployment for a large financial firm in Boston. They have great needs in integrating SQL Server 2005 Reporting Services Reports with MOSS. Microsoft released a Reporting Services Add-in for Microsoft SharePoint Technology for this purpose. However, getting it to install properly isn’t exactly a cake walk. Liam Cleary has a 3-part post details the installation steps.

Post #1: Installation

Post #2: Configuration

Post #3: Report Builder

This helped a lot. However, you still need to be careful. When deploying reports from Visual Studio, you need to setup the targets for both the data source and the report. These should be two separate SharePoint document libraries. This way, you can control the permission to the data sources and the permission to the actual reports independently. It is a good practice for an organization to have much tighter control over the data sources than the reports themselves, especially given the fact that the data sources are usually shared among many reports, and they themselves carry credentials used to access the databases.

One more thing to note is that after the Add-in is installed, the Report Viewer Web Part is not deployed. You have to manually enable it through Web Part Gallery before you can create Report Viewer Web Parts on your WSS portal page.

I was watching Ted Pattison’s MOSS screen casts. And I discovered that you can actually blog directly out of Word 2007. So here it is, my first Word 2007 Blog!

Basically, you create a new document from Word 2007 by going to Start (the big Office icon) àNew, and select “New blog post” option, and hit the “Create” button. If this is the first time you use Word blog function, it will prompt you for setting up your blog account. It supports Windows Live Space, Blogger, MOSS, Community Server, TypePad and WordPress out of the box. And I am sure you can customize for more options if you don’t find yours in there. The rest should be fairly straightforward. This is exact the functionality w.bloggar gives you. But now it is integrated in Word, and it just feels very natural.

In the BizTalk Pipeline component, often times you need to construct new messages out of the received messages in the Disassemble stage before passing them on to the orchestration. This can be done in a few different ways.

The easiest way is to build a concatenated XML string using StringBuilder or something similar, and load it into a new XmlDocument object. However, this is very inflexible. If the structure of the message is changed, the Pipeline component would have to be recompiled and redeployed. Another approach will be to load the XML strings from a configuration file at runtime, or keep it as a separate resource file to be loaded at the runtime. This approach avoids the recompilation process when the XML structure is changed, but you still have to worry about keeping the external XML file in sync with the actual BizTalk schema file.

What if you can programmatically create an XML document based on the your XML schema? Or even better, what if you can use the schema that is validated and compiled by BizTalk and stored in the BizTalk management database? This way you don’t have to worry about manually keeping the schema and the external XML file in synch since there is no external XML file any more. Any change you make in the schema is directly reflected in the Pipeline component when you build your new message. Well, it turns out that there is an undocumented API called “CreateXmlInstance” just for that. Here is the code snippet that does this.

public XmlDocument CreateBTDoc(string schemaName)
{
    XmlDocument doc = new XmlDocument();
    BtsCatalogExplorer explorer = new BtsCatalogExplorer();

    explorer.ConnectionString = @”Integrated Security=SSPI; Server=localhost\SQL2005; Database=BizTalkMgmtDb;”;
    Schema schema = explorer.Schemas[schemaName];

    if (schema != null)
    {
        DocumentSpec spec = new DocumentSpec(schemaName, schema.BtsAssembly.DisplayName);
        StringWriter sw = new StringWriter(new StringBuilder());
        doc.Load(spec.CreateXmlInstance(sw));
        sw.Dispose();
    }
    return doc;
}
Essentially this code would go directly to the BizTalk management database, find the specified schema, and then create an empty XML document based on the schema. To use this code, you need to add references to Microsoft.BizTalk.ExplorerOM and Microsoft.BizTalk.Pipeline assemblies. Your using statements should include Microsoft.BizTalk.Component.Interop and Microsoft.BizTalk.ExplorerOM.

From here on, you can programmatically populate/manipulate the XML element/attribute values as needed. One thing to note is that this code is not entirely immune to changes either. If you add new elements/attributes to your schema (which is the case for most situations), the code will be fine since it simply creates blank values for the new fields. However, if you remove some elements/attributes, or make changes to existing elements/attributes, and if your subsequent processing code access them, you will have to modify the code to accommodate the changes.

BizTalk Orchestration Designer is the core tool for laying out components representing business processes, and connecting them with logic operations when designing BizTalk applications in Visual Studio. Behind the scene, the XLANG compiler actually generates C# source code before compiling it into .NET assemblies. If you ever want to look under the hood and view the C# source, here is a little trick.

Use your favoriate registry editor (I simply use RegEdit.exe), go to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0. This is where some key properties of Visual Studio 2005 IDE are stored. Add a DWORD value named “GenerateCSFiles”, and set the value to 1.

Next time you launch Visual Studio to open a BizTalk project with orchestration files (.odx file) in it, click on the “Show All Files” icon in the Solution Explorer after the project is built. You will see along side with your abc.odx file, there appears an abc.cs file. This is the C# source code generated by XLANG out of your orchestration. You can open the file and view all the code, assuming the compilation succeeded (otherwise the cs file is blank). You will notice all your orchestraction artifacts are actually translated into one big chunk of XML embedded in the C# code.

I was trying to work on some cool OpenXML format for the new Office 2007 System. After I downloaded and installed the .NET Framework 3.0, I couldn’t find the essential .NET assembly WindowsBase.dll that is critical for what I need to do. After much searching around, online and in my harddrive, I found out that .NET Framework 3.0 creates this little directory in C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0. All the goodies including WindowsBase.dll are in here. Doh! Why they didn’t possibly make this a little less obvious is simply beyond me.

After receiving a seond email request this month, I finally took some time to move the InkBoard over from my hacked MIT server. If you are interested in Tablet PC-enabled real time collaborative sketching, check it out. I have not updated the software for a while, and there is no immediate plan for 1.2 version. But if there is enough interest, I will try to make revisions.

The major improvements I made for version 1.1 over version 1.0:

• Remoting is used in place of the direct socket calls.
• InkBoard Server now runs as a Windows Services as oppose to console application.
• Audio/Video conference module is removed since it creates more setup trouble than its worth.
• Toolbar icons improved (still miles away from commercial quality though).

Let me know what you think.