Custom Connector dev and deployment with VSAE (AuthoringExtension) and SCSM 2016? RRS feed

  • Question

  • I am coming again here to ask for some clarity about the development deployment of a custom connector. I am speaking about the connector we see in the SCSM Console like the 'AD connector'. I want to create my own connector to better control the import of my data.

    As said in my previous topic, I am indeed developing a custom import to SCSM, now with SCSM 2016.

    I followed this tutorial to create a custom connector

    As I understand there, a connector is a ManagementPack implementing the SystemManager.LinkingLibrary.LinkingFramework.DataSource

    Or is there another way to create a connector?

    Anyway, this tutorial from 2009 is targeting SCSM 2010. The connector is defined within a class library project. It explains how to write the management pack xml, which refers to the C# class defined in the DLL. It gets deployed by importing the management pack XML into SM and copying the DLL in the SCSM installation folder (%ProgramFiles%\Microsoft System Center\Service Manager 2010 ). This connector defines a workflow rule calling a Powershell script, which contains the real logic.

    In 2016, I am doing the stuff a bit differently: I am using SCSM2016, Visual Studio 2015 and VSAE (VisualStudioAuthoringExtensions), so that I have a much better support to create my Management Pack and can deploy it directly from VSAE. VSAE compile, seal and deploy the MP, and thus list all errors first in Visual Studio before the import into SM.

    I wish I could simply deploy my MP from VS and hoping the DLL gets deployed with them. Has anybody successfully taken that path?

    I created 2 projects: one for the connector MP and one for the DLL defining the forms of that connector (inheriting the WizardxxxPageBase forms).

    In my MP project reference, I added the DLL. First warning here: .NET version conflict. SCSM 2016 is targeting .NET 4.5.1. and thus I targeted my DLLs to that version. But VSAE 1.2.1 (orignally set for SCSM 2012, got an update for SCOM 2016) is not said to be fully compatible with SCSM 2016. Even in my MP refers to the SM 2016 libraries, I don't see how to set the .NET Framework version there (nothing

    However, VSAE is showing me plenty of errors, first starting with key not inherited

    Class ConnectorMP.ConnectorClass does not have a Key property defined directly or through inheritance. Mark this class as Singleton. 
    If I add a direct key property, I get another error, so I need to use the inherited key.

    Reading the key concepts of MP, I still don't know how to let the inherited ID working. Any idea here?

    • Edited by EricBDev Thursday, December 15, 2016 2:10 PM links
    Thursday, December 15, 2016 2:07 PM

All replies

  • Hello,

    I know this is very late but I had the same problem and if someone else finds this.

    I found out that I was referencing the wrong version of the mpb "Microsoft.SystemCenter.Library" where the class "Microsoft.SystemCenter.Connector" is defined.

    The class System.LinkingFramework.DataSource is based on the class "Microsoft.SystemCenter.Connector" and when I referenced the wrong version of the mpb I got the same error as You. The class "System.LinkingFramework.DataSource" doesn't have a key defined in the "ServiceManager.LinkingFramework.Library" mp.



    Friday, August 17, 2018 12:37 PM
  • Answering your first question,  you can bundle the DLL into the MPB that VSAE builds.

    Assuming both projects are in the same solution, in the Management pack project, add a reference to the dll project.  In the properties of the reference, set Package To Bundle to True.

    Then add a management pack fragment with code similar to this

        <Assembly ID="ConsoleTask.EventHandlers" Accessibility="Public" FileName="ConsoleTask.EventHandlers.dll" HasNullStream="false" QualifiedName="ConsoleTask.EventHandlers" />

    Friday, August 24, 2018 7:26 PM