Sometimes trivial things in .NET are not so trivial in the BizTalk world. Especially for standard .NET developers with the mindset for routine .NET development. Recently, I was asked to give a hand with a simple task that was surprisingly taking too long (and good that was asked for, why to waste time if you can leverage someone to give a hand – always something I resort to). On the web, there are plenty of resources, yet nothing emphasizes the little things that are obvious to somewhat experienced BizTalk-ers and is brand new to mature .NET developers. Lets dive into example.

I really like the concept. Wish Hudson build server would have this option…

JetBrains has implemented the idea with TeamCity.

I am looking at the code for Silverlight application and there’s something that just bugs me… INotifyPropertyChanged. This is not the first time, and yet again I see this interface implemented again, and again, and again. This violates several good principles (Single Responsibility and Duplicated Code). It also pollutes the code with cross cutting concerns (change notification). My choice of solution for this is simple – buy, do not build. Yes, it is possible to write a base class that would scan for a custom attribute and will do the wiring. But why? Why not to look into something like PostSharp and take advantage of the hard work the author(s) put into it to make it work.

For most of our projects we use StructureMap as a Container. Silverlight seems to change this a little. From preliminary review looks like StructureMap is not yet ready for Silverlight, so we started to look into a different container. The one that looked good was Ninject. Simple, straight forward, and elegant.

Binding module defines components:

I am getting involved in another project, that looks like has its own testing challenges (last project I was involved was a BizTalk based project, quite a few testing challenges!).

What have I seen so far with Silverlight (version 4.0):

1. TDD with the toolset we always utilized is no longer possible (Gallio, TestDriven.NET, NCover) partially due to the nature of Silverlight, partially because of the tools support that is not yet in place
2. MVVM pattern – developers wrapping around the idea
3. Explosion of Microsoft technologies that are just “out of college” and not yet applicable in TDD case
4. Limited resources on .NET code detours (I only encountered Moles and TypeMock, but for commercial Silverlight product both are commercial)
5. Natural limitations of Silverlight (sandbox, static DependencyObject properties, inheritance from the system)

Looks like this is going to be an interesting journey. Feel free to share your experiences and findings.

This might be helpful for those that work with SVN and require (read-only for now) access to code that is under GitHub

I was writing a custom component to copy message parts of an untyped message, invoked from orchestration. This message was created in a custom pipeline, and body part name had to have “Body”. For some bizarre reason, when message body part is handled outside of orchestration and passed into .NET code as XLANGMessage, body part name is “part”. ??? The other parts have the original names. I have no idea why this is happening, but thought it could save someone a question or two, especially when writing tests and expecting that the name of the part is “Body”.

Sometimes you have to get to the lower level of debugging (ie debugging auto-generated code) to understand what happens. This is what you can do to achieve it in BizTalk.

Link 1 (Auto-generated code)

Link 2 (MMC)

For the project I work on, processing involves multiple files. Files are packaged in a ZIP archive and it’s BizTalk application that opens the archive and builds a message for processing. In BizTalk terminology, this is a multi-part message.

Interestingly, if you search for more information, mostly you’ll find how to receive a MIME message that is already multi-part message (i.e. BizTalk can already handle it) or how to do it with Orchestration, by defining a contract (schema) of the multi-part message. But what if you want to construct your multi-part message within a pipeline? And what if you don’t know how many parts you have?

I have posted before about Bizmonade testing library for BizTalk orchestrations testing. Unfortunately, there’s something something that looks like a limitation – testing orchestrations that receive any document type (System.Xml.XmlDocument). I posted a question on StackOverflow and curious to see if get anything at all. How do you test your general schema orchestrations?

Update 2010-07-08: I’m in contact with the main developer of Bizmonade, and he’ll be releasing soon an updated version that will allow scenario I am looking for.