I've been using the SSO Application Configuration tool for storing key/value config data for my BizTalk solutions, described here: http://blogs.msdn.com/b/teekamg/archive/2009/08/19/sso-configuration-application-mmc-snap-in.aspx, and available here: http://www.microsoft.com/download/en/details.aspx?id=14524.
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...