Just as the event log gets a makeover, so does the registry. In this post, I will take a look at some of the work done around how to manage settings and configuration in the OS. The goal is to provide a platform for handling settings in such a way that supports roaming, migration of settings, transactions and rollbacks, etc. There is quite a bit of work underway to improve the way settings and state are managed by the system.
The new settings infrastructure is composed of three main areas. First is configuration schema, which allows settings to be schematized based on — surprise, surprise — XML. This allows for complex hierarchies of typed settings to be described. Second is a configuration engine that has a suite of APIs for reading and writing configuration settings. Last is a configuration store, which is an optimized store that can be synched with legacy stores such as the registry, INI files, etc.
As usual, the best way to grok this is to look at it in action. (Note that all of this is preliminary and will evolve as Longhorn moves toward beta.)
First, to browse the new store, open a command prompt and launch %windir%\system32\wcmedit.exe. You can see that already, some Windows components are using the store. In fact, the Event Log, discussed yesterday, already has a complex schema registered. Or, you can see that the Shell is also using the store for values such as which wallpaper is in use on the desktop. As you browse through the store, you can see the values are typed based on XSD types, which of course correllate to CLR types.
Notice that every application, represented by a namespace, has three buckets underneath it: metadata, settings and transactions. Perhaps most interesting is the transactions bucket, which allows you to see the activity that has occurred for that application.
Now, let’s take a look at how to register a schema in the store. Here is the schema itself, embedded in the manifest. First, go the the Longhorn SDK Samples and open the WMI tree. Download the WMI.Configuration Sample 1 and unzip it. You will find a file called WcmSample1.man, which is the manifest and schema that the samples application will use. In order to register it, you will need to compile it with the system. In your command prompt, navigate to “%windir%\system32\WMI Config”. Then, type WcmCompile.exe %path to sample%\WcmSample.man. Now, go back to your configuration store manager and hit refresh. You will see your application added to the list. This step will eventually be obsolete and schemas will be “compiled“ when the application is installed, either via ClickOnce or some other installation technology, like MSI.
To see the API in action, compile the sample using MSBUILD. When you run the sample, the application will both read and write settings to the store. After running the sample, browse the trancations folder in the store to see what transpired. Every time you run the .exe, you should see three transactions logged.
To get a sense of how the API works, open up the WcmSample.cs file. In this case we are setting values such as the Window title and the Window size coordinates after getting the application namespace from the store. Here is the source code.
In my next post, I’ll take a look at how to do some more interesting things, like synch with the registry or set restrictions on the valid values for a given setting.