Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assemblies are not Signed #81

Open
Amberg opened this issue Aug 30, 2021 · 5 comments
Open

Assemblies are not Signed #81

Amberg opened this issue Aug 30, 2021 · 5 comments

Comments

@Amberg
Copy link

Amberg commented Aug 30, 2021

Description

The assemblies are not signed and can not be referenced from a signed project.
That's criminal negligence by anybody that creates assemblies used by others, given how trivial it is to give an assembly a strong name while building it. Doing it afterwards is quite painful, you have to decompile the assembly with ildasm.exe and put it back together with ilasm.exe, now using the /key option.

@0x0ade
Copy link
Member

0x0ade commented Aug 30, 2021

Dang, I wanted to give a comment before having the issue closed 😅

Better documentation would certainly help as this is quite obscure knowledge right now, but: You should be able to declare a MonoModRules class that updates MonoModRule.Modder.WriterParameters in its static constructor. MonoMod exposes the Mono.Cecil writer parameters, which should allow you to set any information necessary for strong naming.

@Amberg Amberg reopened this Aug 30, 2021
@Amberg
Copy link
Author

Amberg commented Aug 30, 2021

Ah ok I think I see. Thank you for your hint.. I was just interested in the "MonoMod.RuntimeDetour" package to setup a lightweight Hook. Is this not possible with a signed project?

Is there a reason why the packages are not signed? There is a snk file in the Common project..

@0x0ade
Copy link
Member

0x0ade commented Aug 30, 2021

Ooooh, that's what you meant.

The main reason why MonoMod isn't signed is because it makes drop-in updates by users harder. The runtime seems to have much stricter versioning rules for signed .DLLs, I have yet to understand all the details though. I also remember there being more to it, but sadly not what exactly. I'll try digging up what I can remember 😅

@pardeike
Copy link
Member

Microsoft itself recommends to not sign open source projects. Big corporations or users with signing needs will have to sign the packages themselves.

The main problem here is that signed artifacts are creating lots of problems for ordinary users that have no idea what it means or have no intend to sign their artifacts.

@Amberg
Copy link
Author

Amberg commented Aug 30, 2021

@pardeike Do you have a source for this statement?
I found exactly the opposite. 😄 Here Microsoft recommends to strong name open source libraries:
https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming#create-strong-named-net-libraries

Perhaps we are confusing things here. I am talking about strong naming the assemblies.
As far as I can tell, most open source projects are signed.

As example JSON:
// Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
Mono.Cecil:
// Mono.Cecil, Version=0.11.4.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e

But of course you can also sign the assemblies yourself. But that is a bit tedious.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants