SCSM 2016 – Steps used for upgrading custom development
The new version of System Center Service Manager is coming. TP5 is released and Microsoft communicated that there could be some impact for your custom development. Service Manager 2016 has been upgraded to support .NET Framework version 4.5.1. Along with this change, classes are moved to other dll’s. If you are referencing one of the classes that are move from dll, your development will stop working on the new SCSM 2016 environment. Customization in Service Manager might break if:
- Solutions is targeting .Net Framework version below 4.5.1
- Classes or controls in use that have been moved to different dll
- solutions that have a version (7.1.1000.0) reference to Service Manager assemblies
To fix your custom SCSM solution, you need to run through your projects, update the references and recompile your solution. For some of the customizations it will be as simple as that, for other it goes a bit further to make the solution working again. This blog post will provide an overview of the steps I have taken to update my custom solutions. This will give you a first look on what needs to be done. Not everything can be done at once…so expect a regular update of this blog post. I will update this blog while I’m travelling though my custom solutions upgrade to support SCSM 2016.
To goal of this post is to build a number of upgrade procedures for different flavors of customizations. Feel free to email me or comment on this post to give feedback or share your upgrade procedure/experience. New upgrade procedures will be added on the end of this blog post.
Have fun upgrading your solutions !
Kurt Van Hoecke
0: Prepare your environment, gather the new SCSM 2016 dll’s
Besides the .Net version, dll files need to be updated in some of your projects. I have created a “2016 references” folder and copied all needed dll files from the Service Manager program folder.
Some of the dll files are not directly stored in the SCSM programs folder. The “Microsoft.EnterpriseManagement.ServiceManager.SharedResources.dll” for example can be found in your user profile appdata folder. Navigate in the appdata folder to Local –> Microsoft –> System Center Service Manager 2010 (in my case) –> <your SCSM mgmt. server> –> 7.5.7314.0. In this folder you can find your remaining dll’s.
1: Custom CMDB Classes and form customization mpb
This solution includes several class definitions and supporting forms to provide access to classes and class properties. It is a CMDB extension that is create partially in Visual Studio Authoring Extensions (Classes, relationships, views) and forms are created a separate project in Visual Studio. This dll is referenced in the VSAE solution to create to mpb file to import.
- Classes are defined in the VSAE project. No specific custom “tricks” done in this mgmt. pack…the classic way to define your classes for SCSM.
- Forms that have bindings to these classes are using the controls for SCSM.
For these forms; we need to upgrade the project to .NET 4.5.1
- SMControls are used, we know some controls are rehomed to other dll.
- Some custom code behind to make everything working for this solution. Listviews, for example, are defined in these forms to visualize the relationships between the custom classes.
Open the project in Visual Studio and open properties of the project. On the Application tab update the Target framework to .NET Framework 4.5.1
The next step is to update all your references in your project. I think that you normally you only need to update the one that are changed. Because your solution will not be backwards compatible it is safe to update all your references.
Most references in this project are UI dll’s. To give a view on this, a screenshot of references for this project is added below. After updating the SCSM references they all have version 7.0.5000.0
Custom forms are UserControls and this XAML file need to be updated with the correct dll refrences. Some of the controls for SCSM are changed and need to be “moved” from SMControls to SdkDataAccess dll’s. In this project there is a reference added as illustrated below.
Resource definition in the UserControl doesn’t need to be updated, the SCSM 2016 dll was updated in the beginning of this procedure.
One control that is changed from dll is the listpicker. All listpicker definitions in your UserControl forms need to be updated to reference the correct dll. For this project the smcontrol2 need to referenced for the listpicker.
This needs to be done for every control used in the form that is changed from dll. Listpicker is one of them, most common used are the one used for building up forms. A warning is displayed in Visual Studio that the control definition cannot be found. So you directly know the used control needs to reference a different dll.
To give an idea of the changes…
Note: In this project I had issues updating the listpicker definitions in the xaml code. Although all syntax was correct the form didn’t display. After explicit naming all listpickers in the forms, the forms displayed correctly. This can be a specific issue for this project or a change in the listpicker definition for SCSM 2016.
All done, dll compiled correctly and can be integrated in the VSAE project.
Findings, results or other relevant feedback after testing the solution will be added to this part of the blog.
2: AssignDirectly custom task
The AssignDirectly task is a custom SCSM task to automate the incident and service request mgmt. processes. This solution makes the connection between a support group and an Active Directory security group. It holds classes to define the configuration and a form that is displayed at runtime of the task.
Class definition is used for holding the connection between a support group and the AD security group.
A Form is displayed when the task is executed to make the selection.
Task definition in mp
< To be completed >