SCSM 2012 R2–Adding a Base Enumeration to a Custom WPF Form

Using SC Service Manager 2012 R2 UR2;

I recently had a request from one of my customers to use an existing enumeration from the System.Library management pack within their custom WPF form.  This would mean using the SCSM List Picker control and binding it to the field with the value constraint tied to the enumeration.  This is super straight forward through the SM Authoring Tool, however, when developing a custom form within Visual Studio using WPF, the process is not as simple.

Doing a quick Bing search yields a CodePlex project to use for reference:

Using this as reference, we can see adding the namespace in for the SC WPF controls is pretty straight forward:



You may already have this as part of your project if you already developing a custom form.  If not, add it in and the listpicker control will be available through smcontrols:ListPicker.  Interestingly, the List Picker in this project is also available through the XML namespace scwpf via scwpf:ListPicker through the following:


They both point at Microsoft.EnterpriseManagement.UI.WpfControls.ListPicker so either is fine.

Here is the code that actually adds the List Picker onto the form from the sample project:

ParentCategoryId=”{Binding Source={x:Static
SelectedItem=”{Binding Path=Classification,

Perfect.  The catch here is that I want to add Object Status to my form and the enumeration is defined in the System.Library management pack.  In the case of the example, an enumeration from the existing project was used and it is accessible through the “local:” namespace.  I could be missing something here, but I was not able to get a namespace added for the System.Library mp.

The ParentCategoryId really just gets set to the GUID of the enumeration that SCSM assigns the type when it gets created.  Something like this will work:

<scwpf:ListPicker Name=”listObjectStatus”
HorizontalAlignment=”Stretch” Width=”Auto”
SelectedItem=”{Binding Path=ObjectStatus, Mode=TwoWay,
UpdateSourceTrigger=PropertyChanged}” />

In order to get the GUID, I used PowerShell and connected to he SDK for my SCSM environment:

$mp = Get-SCSMManagementPack -name ‘System.Library’
$mp.EntityTypes.GetEnumeration(‘System.ConfigItem.ObjectStatusEnum’,$mp) | Select ID



The GUID should hold constant across management groups so this should be ok…should be ok.  At this point, I really don’t trust that this code will be ok forever and I dislike hardcoding values like this.  It seems that the chance for the GUID to change would definitely exist between environments or maybe as part of an upgrade to a future version.  One would hope not, however, I don’t want to leave it to chance.

Digging further into the CodePlex project, I find this code:

//*** IMPORTANT NOTE: The IManagementGroupSession is not a part of the publicly document/supported official SDK and is subject to change in a future release.
IManagementGroupSession session = (IManagementGroupSession)FrameworkServices.GetService<IManagementGroupSession>();
EnterpriseManagementGroup emg = session.ManagementGroup;

Nice!  It’s the SDK we all know and love.  I poked around a little to see if IManagementGroupSession is documented and supported now.  I didn’t find anything definitive, however, this chunk of code seems to be all over.  In the event that these calls get changed in a future version, the workaround/fix should become available fairly quickly afterwards since it would seem many people/customers would now have a dependency on this code. Thus adding the following as well:

gdObjectStatus =  new Guid();
gdObjectStatus = emg.EntityTypes.GetEnumeration(“System.ConfigItem.ObjectStatusEnum”,
new Version(“6.0.5000.0”))).Id;
listObjectStatus.ParentCategoryId = gdObjectStatus;

We end up with the GUID for the System.ConfigItem.ObjectStatusEnum as defined in the System.Library management pack assigned to the ParentCategoryId for the SC WPF List Picker control.  Now, the XAML for the control can be simplified and the GUID can be removed:

<scwpf:ListPicker Name=”listObjectStatus”
SelectedItem=”{Binding Path=ObjectStatus,
UpdateSourceTrigger=PropertyChanged}” />

Much more simple.  Looking at the custom form, here is the newly added control attached to the Object Status Enum:


No more hardcoded GUIDs.  A similar process can be used to get ahold of any GUIDs or objects you want to use on your forms.  Additionally, using the C# code, you can get at any other objects that may in fact not have static GUIDs such as specific instances of a CI or Work Item.

Leave a Reply