Freigeben über

OpsMgr MP version number format – issue with mpseal.exe

  • Artikel

Today I tried to seal a MP but got a strange error from mpseal.exe:

Attempting to seal ManagementPack file: MyMP.xml: Failed with the following compiler errors during assembly creation: c:\Users\Dirk\AppData\Local\Temp\a7ohotqr.0.cs(3,30) : error CS0647: Error emitting 'System.Reflection.AssemblyVersionAttribute' attribute -- 'The version specified '10.4.2013.2015040901' is invalid'

Hmm, strange, the MP could be imported into the Management Group as a XML file without any problems…

At first I was a bit slow on the uptake and searched for the error CS0647 and then asked one of our engineers (thanks Mihai!). He immediately pointed me to the “wrong” MP version number.
So I changed the version number in the XML to '10.4.2013.1’ and mpseal.exe ran fine.

But I was not really happy with that! Ok, you could ask: Why do we need such a long number as a part of the version number?
I really like to place the last modification date and a continuous number as the revision number in my MPs, that is why I use yyyyMMddnn as the MP revision number.

So  I did some more research:
Looking at the current Schema reference at TechNet it states, that:

The value must consist of 4 numbers of up to 10 digits in length.

So '10.4.2013.2015040901' should be syntactical correct...

I did some more tests and can verify that mpseal.exe (with file version 7.1.10226.0) accepts MP version numbers in the XML only in form of:
<Int16>.<Int16>.<Int16>. <Int16>

So:
65534.65534.65534.65534 will work
65534.65534.65534.65535 (and above)  will not work

Conclusion

  • When using mpseal.exe for sealing MP use version numbers in a format
    <Int16>.<Int16>.<Int16>. <Int16>
  •  The parser in the SCOM console accept 4 numbers of up to 10 digits in length, so for unsealed MP there is no such problem.

Happy MP sealing :)