FarPoint just released a pipeline disassembler component for Excel documents (called "FarPoint Spread for Microsoft® BizTalk® Server 2006"). It looks pretty cool! It comes with a "Spreadsheet Schema wizard" that integrates with Visual Studio 2005. It could potentially save a lot of work.

I guess the reason that Microsoft hasn't released anything like this is that they like to push the use of Infopath. Basically everything would be much easier if one uses Infopath, but there might be situations where this isn't possible.

As most people know the web project that are created and tested in VS 2005 run on an internal web server (called Cassini).

In some situations this is useful as it enables one to quickly get the project up and running and start testing. But as the sites usually are going to run on an IIS in production I usually like to test it and develop it on one as well (for other reasons, check this out).

Here's a good article on how to change the setting that makes VS behave as it it used to (put it on an URL and create a virtual directory for it).

The only drawback I can think of is that it becomes a bit more complicated when it comes to deleting a project ...

I found a couple of really good webcasts here!

I just found the FileSystemWatcher class in the System.IO namespace. It provides the functionality to listen on the file system for changes on a file or directory. The class fires a couple of events: Changed, Created, Deleted and Renamed.

I didn't know of this class until now. I always thought one had to write a service to accomplish something like this! Definitely very useful!

I've just started reading the new BizTalk Server 2006 Troubleshooters Guide, it's basically 133 pages packed with best practices and common pitfalls to avoid. It's seems to be a great resource and I'll try to use this blog to summarize some of the different parts - just have to get some more time! ;)

A while ago Microsoft released the CSS Control Adapter Toolkit for ASP.NET 2.0. It finally makes it possible to use all the time saving ASP.NET controls in 2.0 without all the horrible HTML they used to produce. The toolkit gives access to the now improved source of the following adapter controls:

• Menu
• TreeView
• GridView
• DetailsView
• FormsView
• DataList
• Login
• ChangePassword
• CreateUser
• PasswordRecovery
• LoginStatus

Make sure to have the latest update. The update fixed a few things in the old controls and added a couple more.

One can almost think of the this toolkit as a patch for ASP.NET and when creating a public website this really is a must!

I've realized that I never understood the full potential of the Visual Studio Database Project. None of the projects I've worked on has had a effective process on handling changes and versioning of the database schema. Test data, build scripts, changes to the local development database versus the test and production base has also been a bit bumpy. I've haven't understood that working with the Database Project potentially could solves a lot of these challenges .

A chapter from the Database Access with Visual Basic® .NET book describes some features in the Database Project.

Today someone complained about Windows XP's lack of virtual desktops and that Mac had the possibility to have several desktops active with different content. I remembered that had tried something like that a couple of years ago and after a while I found Microsoft PowerToys for Windows XP again.

The PowerToys package contains several small XP add-ins. For example the Virtual Desktop Manager!

As the image above show the manager makes it possible to have four separate desktops running at one - nice! A few configurations tips that I found useful was turn of the shared desktops option and to set the shortcut for showing the desktops to alt-§ (that's close to the alt-tab option).

An other cool application in the PowerToys package is the Alt-Tab Replacement that shows a small preview of the different windows one is multi tasking between (as shown in the image above).

We ran into an issue today when we had to have an XML comment just below the XML declaration in a message we're producing in our BizTalk 2006 solution. We needed to produce something like the below.

<div><span style="color: #0000FF; "><?</span><span style="color: #FF00FF; ">xml version="1.0"</span><span style="color: #0000FF; ">?></span><span style="color: #000000; ">
</span><span style="color: #008000; "><!--</span><span style="color: #008000; "> Comment goes here </span><span style="color: #008000; ">--></span></div>

Our first approach was to create a map in the send port and to have a custom XSLT template in there that added the comment before the whole transformation process started. We actually got this to work but it meant that we had to have a whole new map with a separate XSLT document in the project!

Eventually we found a property called Xml Asm Processing Instructions (highlighted in the figure - click it to view it in original size) on the XML assembly component (used in the standard XMLTransmit pipeline).

We just put the comment as a value in this property and we were done! No new artifacts or code! Just a weird property - typical BizTalk behavior!

I'm a loyal ARcast listener and I think I've listened to most of the shows that ever been produced (at least those that are available in the archive). I also listen to a couple of other podcasts that are focusing on .NET and Microsoft techniques (for example .NET Rocks!) and in my opinion ARcast is by far the most rewarding (I guess this is both a matter of taste and depending on what kind of work one does.)! However these two shows on Patterns and anti-patterns for SOA (part 1 and part 2) really stands out!

They really got me thinking of a couple of anti-patterns the project I'm currently working on are stuck in. And Ron Jacob delivers (as always) the message with a lot of humor and enthusiasm. Recommended!

I'm currently working in a stabilization phase on a deployment application for BizTalk 2006 projects. We based the solution on the Enterprise Solutions Build Framework and the BizTalk Explorer Object Model. Basically our solution has a GUI that makes it possible to point out which artifacts one likes to deploy (from the developers local BizTalk server).

The application then figures out all the dependencies that the selected artifacts has (In our solution an Orchestration for example might have > 20 dependencies to different schemas, pipelines, C# libraries etc, etc).

All DLL:s of the different artifacts are then extracted from the local GAC (where they exist when deployed to the local BizTalk). These DLL:s are then packed in to one single deployment package also containing a single XML file that keeps track of the dependencies and the order of witch they have to be deployed in BizTalk (the most depending schemas first and so on). The XML file also contains other meta data information such as ports the artifacts use etc.

This package is then loaded into another part of the application were it's possible to point out the different servers one like to deploy to. This view then shows information about what has to be done on the server to make it possible to deploy without conflicts (One might have running Orchestration or suspended messages for example that has to be stopped or terminated.). At this stage we also check the naming of the different artifacts. These have to comply with the naming conventions that are configured in the config file of the applications (a warning is shown if the artifact doesn't validate towards these).

When no warnings (its possible to override a warning) or conflicts are shown one can deploy. We then move the deploy scripts to the servers and use the MSBuild tasks in the SBF to deploy everything for us. We really saved some serious time with this approach and even if it took us a while to get everything working it's been well worth it!

We have a huge feature list for the next phase of the tool and are planing to and support for BizUnit tests in the DLL:s (so that one gets a warning when deploying a Orchestration without etc). We also like to add more meta data about the port and make it possible to configure new ports as a part of the deployment process. Etc, etc ...

Feel free to comment or write we line for further information about this approach. It would also be interesting to hear about other approaches for deployment and what kind of features these solutions have.

Understanding Xpath expressions is definitely a success factor when working with BizTalk development. Xpath is extremely powerful (when one gets it right) but it's one of the must frustration techniques I've ever worked with! Xpath is one of those languages that either gives you to answer you want to a query - or (more often) just doesn't give you anything in return! In 99 percent of the cases this means that you missed something in your match. In 99 percent of these cases this means that you got some problems with namespaces in the XML document your querying (This is certainly true when working with BizTalk that "namespace-heavy"). One technique to get around this is to use the same approach as BizTalk itself uses - the Xpath local-name() function!

Consider the following XML document.

<div><span style="color: #0000FF; "><</span><span style="color: #800000; ">Message </span><span style="color: #FF0000; ">xmlns:ns0</span><span style="color: #0000FF; ">="Standard.Envelope/1.1"</span><span style="color: #FF0000; "> xmlns:xsi</span><span style="color: #0000FF; ">="http://www.w3.org/2001/XMLSchema-instance"</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
    </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">ns0:Envelope</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
        </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">Header</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
            </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">MessageTypeInfo</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
                </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">MessageType</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">.</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">MessageType</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
            </span><span style="color: #0000FF; "></</span><span style="color: #800000; ">MessageTypeInfo</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
            </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">Action</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">INSERTED</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">Action</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
            </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">Addressees</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
                </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">SenderCode</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">Mill</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">SenderCode</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
            </span><span style="color: #0000FF; "></</span><span style="color: #800000; ">Addressees</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
        </span><span style="color: #0000FF; "></</span><span style="color: #800000; ">Header</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
    </span><span style="color: #0000FF; "></</span><span style="color: #800000; ">ns0:Envelope</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">Message</span><span style="color: #0000FF; ">></span></div>

The Xpath expression below will hit the Envelope node. But is's very fragile! As soon as the namespace prefix changes (It might change to ns1 and namespace ns0 will be used for something else.) you'll end up with an empty result.

<div><span style="color: #000000; ">/Message/ns0:Envelope</span></div>

However, if one uses the below expressions instead - that makes use of the local-name function - it ignores the namespace and only cares about the name of the node (Envelope that is ;)). And this is of course far less sensitive to change.

<div><span style="color: #000000; ">/Message/*[local-name()='Envelope']</span></div>

A couple of months ago I found the new Gmail mobile application. It's a clean small Java application that one downloads to the mobile phone for accessing the Gmail account.

The application has easy access to almost all of the features that the ordinary web interface has. There was (and probably still are) an mobile version of the web interface but it didn't have the easy access to all the different menus as this application has. I really like it and use it several times each day.

The supported devices are listed here and to get on your phone all you do is to visit this URL http://gmail.com/app with your device.

Another cool little application is the Opera Mini browser. These a full feature list here. Basically it transforms the pages so that they fit the mobile screen, and it's fast! It also has some special features for navigation on small screens. And it supports RSS bookmarks!

Today was another day of new BizTalk problems ... The task was easy; produce a XML file and send to a receiving system. Fine. Done. ... Not.

The receiving system could not read the file because of some strange characters in the beginning of the file! It looked something like the below when opening the file in a fancy text editor (UltraEdit or TextPad for example).

<div><span style="color: #000000; ">i»¿</span><span style="color: #0000FF; "><?</span><span style="color: #FF00FF; ">xml version="1.0" encoding="utf-8"</span><span style="color: #0000FF; ">?></span></div>

After a couple of very interesting (:/) hours of Googling) I found this from Ben McFarlin

>> It is because internal BizTalk messages are in UTF8 format and include the byte order mark. When you added the xml declaration for UTF16 it confused the engine; the declaration read UTF16 but the byte order mark indicated UTF8. >>

When I finally found the cause the solution was easy. Just another of those weird properties ... This time it's called Preserve BOM (on the properties of the XML Assembly pipeline component - see figure on the right). BOM of course stands for Byte Order Mark.

Scott Colestock has a vary thorough article on TechNet about MOM 2005 and BizTalk. It's really amazing what it possible to accomplish when one gets these two solutions to play together.

Found this article on the code project on how to set a custom name on a output file - something I recently had to do. It also contains a list of all the macros that are available in the file adapter - so does this post from Owen Allen.

Today we ran into some problems when making a call to a web service that took more than 90 seconds via the SOAP adapter. After 90 seconds we got a "System.Net.WebException: The operation has timed-out" error in return. It turned out that we had to set the SOAP.ClientConnectionTimeOut context property for the request message. We did this in the message construction using the following code.

<div><span style="color: #000000; ">MyRequestMessage(SOAP.ClientConnectionTimeout) = 200000;</span></div>

I found this post by Thomas Restrepo useful for understanding both the problem and solution. Apparently the default value is 90000 (90 seconds) before the adapter times out. This article on MSDN is also an excellent read when working with web services and BizTalk server.

As one of the most important rules for a test is that it can't rely on state, I've always found automated data access testing hard. As I view it there are three approaches to accomplish reliable testing of such a layer:

1. A local database that is restored for each and every test.
2. Using transactions that can rollback the database after the test completed
3. Using mock objects

I guess all of them has drawbacks and are suitable in different situations.

It would be possible to have ones data access layer connected to a local database that's fully restored to a know state for every test. But as the database grows that process would soon get extremely slow. And as one of the requirements for testing and test driven development is that is possible to test often (and if we like to test often is has to be fast) I think this is a method that only works when we have a simple tiny database (something we almost never have ...).

Another way of do it would be use transactions to rollback each test operation on the database. A problem here is that we might use transactions within the access layer we like to test! We might even have transactions disabled. This excellent article by Roy Osherove discusses the possibilities of using the transactions from Enterprise Services (COM+) for rolling back database operations. This is an interesting approach and with the new System.Transactions namespace in .NET 2.0 things should be even easier. But still, if one is using transactions in the actually access layer that is being tested we still have to use something else. Another problem is that transactions always will cause a minor performance hit that might grow when using it in a large project with loads of tests.

And then we have mock objects. The first thing we have to think about here is what we should test in a unit test? Should we really test the all the way to the database or should we stay within the boundaries of the application? My option is that a unit test should not test all the way through to the database, then it's a integration test. However it might be very useful to have such a test in our test suite. If we decide to actually test trough to the database mock object will not do us any good. They will only be able to test that the right method in the data access class were called in correct order.

Some links I found useful:
http://weblogs.asp.net/rosherove/archive/2004/12/10/279258.aspx
http://weblogs.asp.net/rosherove/articles/dbunittesting.aspx
http://weblogs.asp.net/rosherove/archive/2004/07/20/187863.aspx
http://msdn.microsoft.com/msdnmag/issues/04/10/NMock/default.aspx
http://msdn.microsoft.com/library...testwithnunit.asp
http://msdn.microsoft.com/msdnmag...default.aspx

I found this post from Richard Seroter's blog on persistence points interesting. The post deals with the basics in persistence points and how to tweak them to get a resumed orchestration to resume at an expected step. Not understanding persistence point and not thinking about them when planing and building an orchestration might cause some strange bugs and errors.

UPDATE: This does not apply to BizTalk ... I've made an update post here. Sorry.

We're working with a lot of code libraries that we use in different parts of our BizTalk solutions. As the are used on several servers and by loads of different "BizTalk parts" (both in orchestrations and maps) it's important that we always keep the version number of the assemblies up to date. That means that every little change should increase the current version number. But as they are used in so many places people have started to skip this step as they thought they had to compile all parts that should use the new code (say it's a bug fix and you'd like all "using parts" of the assembly to load the updated version). This is where GAC loading policy comes to the resource!

First we have to understand that every .NET assembly is identified using four characteristics:

• Assembly name
• Major or minor version
• Public key token
• Culture

Then we need to know that the first version number in for example version 1.1.2.1 is the major version. The second is the minor version and the third and fourth are build, revision version number. So this means that if you have 1.1.2.1 installed and make a minor change the easiest way to use the new assembly is to change the one of the build or revision numbers (the third or fourth number). Then the CLR will load the new assembly without any other changes!

But sometimes we have to change the minor or major version - and we still don't have to recompile a thing! We can use a publisher policy file. This is an example of such a file defined for version 1.0.0.0 moving to 2.0.0.0.

<div><span style="color: #0000FF; "><</span><span style="color: #800000; ">configuration</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
    </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">runtime</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
        </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">assemblyBinding </span><span style="color: #FF0000; ">xmlns</span><span style="color: #0000FF; ">="urn:schemas-microsoft-com:asm.v1"</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
            </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">dependentAssembly</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
                </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">assemblyIdentity </span><span style="color: #FF0000; ">name</span><span style="color: #0000FF; ">="BaseHelper"</span><span style="color: #FF0000; "> publicKeyToken</span><span style="color: #0000FF; ">="18517ea673f8584b"</span><span style="color: #FF0000; "> culture</span><span style="color: #0000FF; ">="neutral"</span><span style="color: #FF0000; "> </span><span style="color: #0000FF; ">/></span><span style="color: #000000; ">
                    </span><span style="color: #0000FF; "><</span><span style="color: #800000; ">bindingRedirect </span><span style="color: #FF0000; ">oldVersion</span><span style="color: #0000FF; ">="1.0.0.0"</span><span style="color: #FF0000; "> newVersion</span><span style="color: #0000FF; ">="2.0.0.0"</span><span style="color: #0000FF; ">/></span><span style="color: #000000; ">
            </span><span style="color: #0000FF; "></</span><span style="color: #800000; ">dependentAssembly</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
        </span><span style="color: #0000FF; "></</span><span style="color: #800000; ">assemblyBinding</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
    </span><span style="color: #0000FF; "></</span><span style="color: #800000; ">runtime</span><span style="color: #0000FF; ">></span><span style="color: #000000; ">
</span><span style="color: #0000FF; "></</span><span style="color: #800000; ">configuration</span><span style="color: #0000FF; ">></span></div>

This kb article describes what to do next:

1. Change the version and recompile. The first step is to create the new version of your component. After you've done that, you will need to modify the version number in the AssemblyInfo file for your component.
   Create the publisher policy file. Create the publisher policy file for the assembly using the format shown above.
   Use Assembly Linker (Al.exe) to create the publisher policy assembly. The Assembly Linker is included with the .NET Framework SDK. To create the publisher policy assembly that redirects a binding from version 1.0 of Website.dll to version 2.0 using a publisher policy file called website.config, run the following command:

   al /link:BaseHelper.config /out:policy.1.0.BaseHelper.dll /keyfile:c:\keyfile.snk

This command will create a new assembly called policy.1.0.BaseHelper.dll. This naming convention is important, as indicated in the "What Is a Publisher Policy Assembly?" section.

1. Install the publisher policy assembly into the Global Assembly Cache. The publisher policy assembly is installed into the GAC. It will be used by the .NET runtime when any application attempts to bind to version 1.0 of the BaseHelper.dll, and it will force the application to bind to the new version automatically.

2. Install the new version into the Global Assembly Cache. Install the new version of the component into the GAC. After the new version has been installed, the old version can be safely removed.

So no more excuses for not updating the version number!