Wednesday, September 14, 2011

BizTalk SSO Application Configuration Usage Note

I've been using the SSO Application Configuration tool for storing key/value config data for my BizTalk solutions, described here:, and available here:

I discovered today that an assumption I’d been making about this tool was incorrect.

You can export the configuration for a particular application to an encrypted “.sso” file (you need to provide a password during the export process). Commonly I do this and include the file in my Visual Studio solution, so that others working on the project can use it to subsequently import the same settings into their local SSO Application Configuration tool. It also enables the settings to be under source control.

The assumption I’d been making was that if you import the .sso file over the top of an existing application, it overwrites the existing settings with those in the file. This is not correct. The import only adds new key/value pairs that are not present in the application you’re importing into – it doesn’t delete key/value pairs that are no longer present in the file, and it doesn’t update existing key/value pairs if the value in the file is different to the existing value. I don’t like it.

This behaviour is documented in the Readme.txt that comes with the tool, but I must admit I hadn’t ever paid it much attention:

4.  Export Configuration Application

... if you add key/value pairs to an application and you wish to export the new values, export the application and when you import only the new key/values will be imported.  It is important to note that if existing values are changed then you will need to open the snap-in in the other environment and make those changes manually.  This was done intentionally because there are times that the same keys will have different values for different environments.
5.  Import Configuration Application
... If the application was new for this environment you will see a new application in the application tree.  If this application already existed you will see new key/pairs added to the existing application.

The only safe way to ensure that you have a verbatim copy of the settings in the exported .sso file is to delete the application first, then import it.

BTW, I came across this because I’m looking at trialing the msbuild task that comes with this tool to take care of the import as part of a dev deploy. Looks like I'll probably need to also include a build task to delete the SSO affiliate application first...

Code Contracts in .NET 4.0

Today I started using a new .NET 4.0 feature called “code contracts” in my Visual Studio solutions. What these do is enable you to enforce preconditions and postconditions in your .NET methods. So for instance, a method that previously looked like this:

public static string GetValue(string key)
  if (string.IsNullOrEmpty(key))
    throw new ArgumentException("Key is required.");

  string result = default(string);

  // Code to determine result...

  if (string.IsNullOrEmpty(result))
    throw new Exception("Unable to determine Value based on Key.");

  return result;

Can be simplified to this:

using System.Diagnostics.Contracts;


public static string GetValue(string key)
    "Key is required.");
    "Unable to determine Value based on Key.");

  // Code to determine and return result...

Obviously the more checks your method has, the more it simplifies thingsRequires checks a precondition, and Ensures checks a postcondition.

Support for code contracts is baked in to .NET 4.0, but you need to install an additional component to enable design-time support in Visual Studio. You can download it from here: Make sure you close any running instances of VS prior to installing.

After the install you’ll have an extra "Code Contracts" page in your project’s property pages. The only settings I’ve changed are:
  • Assembly Mode: Standard Contract Requires – according to the doco it sounds as though you should use this unless you have a good reason not to.
  • Perform Runtime Contract Checking: Checked – without this, your contracts won’t be enforced.
  • Assert on Contract Failure: Checked – I check this for my Debug build so that I get a visible Assert message when my contracts are violated.
Some more information here:
I’ve only just started using this, so my understanding will probably evolve as time goes on, but it looks pretty useful.