Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
MonoGame Not Strongly-Named Assembly #4147
I'm trying to use MonoGame inside my application (which must be signed), but I can't because MonoGame assembly (and the referenced SharpDX assemblies I've noticed) is not signed (is not a strongly-named assembly). Is it possible to sign them (at least the NuGet version)? I'd rather not have to go through the fuss of building my own version of everything just to sign them.
The major problem is that some MonoGame Pipeline dependencies are not all signed, which prevent the ContentPipeline project to be signed (and therefore the core MonoGame library too because it has friend assemblies with the pipeline).
It would be useful to have at least signed versions of MonoGame.Framework.dll for publishing purpose (the pipeline would still require the non-signed one, because assembly friendship can't be given to signed assemblies if the other one isn't).
@danzel I think you have that backwards. You can used all the signed assemblies you want, and not be signed yourself. Just think about the .NET framework. All those assemblies are signed, but that doesn't force you to sign your assembly to use them. Only if you're signed, can you NOT reference unsigned assemblies. This is why I'm requesting it. I have a signed assembly and I cannot use MonoGame because they are not signed.
@mrhelmut Thanks for the reasoning. Sounds like those dependencies need to be signed as well then. It may not be easy, but it is sure a headache when projects like this aren't signed and become a show stopper...
I assume there is some command line tool to do it. I assume we need some sort of certificate... possibly the same one we can use for signing installers.
Assuming we have to get any 3rd party assemblies we use in the pipeline to be signed. I suspect we won't be signing the pipeline itself. That said the pipeline executes via the MGCB.exe... I don't think you need that signed to be able to execute it.
Anything else i'm missing here?
It is either a build step or a command line tool to sign an assembly with a private key (that cannot go in source control). I believe we have keys somewhere. Dean out Dom should know where. If the MonoGame assembly itself is signed, any assemblies it loads need to be signed. It should work if MGCB.exe is not signed and the content pipeline is not signed, but the MonoGame assembly is signed.
Here is a summary of the MonoGame changes in our fork regarding strong-name signing. I also add a copy of my notes on strong names for readers who are less familiar with the topic:
What is strong-name signing?
Strong-naming a .NET assembly creates a unique identity for the assembly by signing it with a private key. For more detailed information just google "strong name signing" and read the MSDN articles.
Following terms are used in the literature: to sign with a strong name, strong-name signing, strong-naming, signed DLLs, strong-named DLLs
Why use a strong name?
If you strong-name your assembly, then you cannot reference other .NET DLLs without a strong-name. Getting strong-named DLLs for all third-party references can be very annoying and slows development down. For example, I built MonoMac, SharpDX from source to add missing strong names.
How to sign an assembly?
Create key pair:
How to get the public key (public key token)?
Sometimes you need to specify the public key token, e.g. in the InternalsVisibleTo attribute. To get the public key token from a strong-named DLL call:
Necessary MonoGame change
In our fork we sign the MonoGame.Framework DLLs and the MonoGame.Framework.Net DLLs. We do not sign the MonoGame.Framework.Content.Pipeline DLLs because most users will not reference them directly and we did not want to spend time signing all referenced third party DLLs.
We use bait-and-switch PCL. This works only if the PCL DLL and the platform-specific DLLs are all signed or all unsigned, e.g. you cannot sign only the Windows build.
Following changes were necessary:
Where to store the .snk key file?
Ideally, the .snk is kept private and secure. I think this is the case in SharpDX: The official packages contain unsigned DLLs and signed DLLs with a key which is kept private.
Strong-naming projects is annoying if you have to build third-party DLLs yourself to add a strong name or if you have to pester the original author to supply a strong-named build. Recently I discovered tools which can add a strong-name to a DLL (without needing the source code). The most interesting tool is: .NET Assembly Strong-Name Signer (http://brutaldev.com/post/NET-Assembly-Strong-Name-Signer, https://github.com/brutaldev/StrongNameSigner/).
I see a few ways how MonoGame could handle this:
In my opinion, the first option is the best solution. Properly strong-name sign all DLLs, store the key publicly in the MonoGame repository. (All other solutions create a fragile ecosystem where third-party developers and middleware providers need to come up with their own strong-name signing strategy. As a result, the third-party DLLs won't be compatible anymore.)
@tgjones Would you also need strong-named versions of the MonGame content pipeline DLLs for your VS extension?
@Helikin That's a great write-up, thank you.
The short answer is no, at the moment I don't. (A more complete answer would be: my scene editor extension does include a tool window that displays rendered content previews, but it doesn't build the content itself - it relies on the content already having been built by the user. In order to extract the available content items from the .mgcb, it relies on
Just to make this less abstract, here's the current state of the VS extension I'm talking about: