Skip to content
This repository has been archived by the owner on Dec 18, 2017. It is now read-only.

Skip strong name signing on Mono until Roslyn supports it #2558

Closed
akoeplinger opened this issue Aug 25, 2015 · 12 comments
Closed

Skip strong name signing on Mono until Roslyn supports it #2558

akoeplinger opened this issue Aug 25, 2015 · 12 comments
Assignees
Milestone

Comments

@akoeplinger
Copy link
Contributor

Building projects that specify a keyFile in project.json (like serilog) doesn't work on Mono currently since the following error is generated:

error CS7027: Error signing output with public key from file '../../assets/Serilog.snk' -- Assembly signing not supported.

Since signing isn't supported by Roslyn on non-Windows platforms yet, signing should just be skipped and a warning printed instead.

@moozzyk
Copy link
Contributor

moozzyk commented Aug 25, 2015

On Mono you should be able to sign with OSS Sigining by using "strongName" : true instead of `"keyFile" : ...".

@akoeplinger
Copy link
Contributor Author

@moozzyk that doesn't help me for projects which I don't control 😄

@akoeplinger
Copy link
Contributor Author

To be clear, I can just remove the keyFile from project.json and it builds fine, but that is annoying and means a subpar out of the box experience when working with community projects on Mono.

@moozzyk
Copy link
Contributor

moozzyk commented Aug 25, 2015

@akoeplinger - I wonder why not commit a change to the project and change the signing to OSS? If the snk is distributed with the project then I think there is not much difference between this and OSS signing. If snk is not distributed with the project you would not be able to compile anyways.

@davidfowl
Copy link
Member

@moozzyk the only valid reason would be because of it being a breaking change.

@moozzyk
Copy link
Contributor

moozzyk commented Aug 25, 2015

@davidfowl Yeah, you're right. How about falling back to OSS signing + warning if the platform does not support snk?

@akoeplinger
Copy link
Contributor Author

That sounds OK to me as well.

@glennc
Copy link
Member

glennc commented Aug 26, 2015

@moozzyk Would you be likely to fit this into beta8 or should we assign it to the next milestone?

@borgdylan
Copy link

Will this be done specifically for roslyn? Compilers based on IKVM.Reflection should not have issues signing with an SNK on mono. So the decision of not supporting SNK on mono should be the compiler's decision.

@davidfowl
Copy link
Member

This issue is about the roslyn compiler.

@Illeris
Copy link

Illeris commented Sep 2, 2015

Same issue on Windows, providing a ".snk" file in WithCryptoKeyFile:

CSharpCompilationOptions compilationOptions = new CSharpCompilationOptions(Microsoft.CodeAnalysis.OutputKind.DynamicallyLinkedLibrary).WithCryptoKeyFile(String.IsNullOrEmpty(ca.AssemblySigningFile) ? null : ca.AssemblySigningFile);

@davidfowl
Copy link
Member

@Illeris what?

@muratg muratg modified the milestones: 1.0.0-rc1, 1.0.0-beta8 Sep 22, 2015
moozzyk pushed a commit that referenced this issue Oct 14, 2015
If project json contains the `keyFile` property the assembly should
be signed using the provided snk. However real signing is not
supported on Mono. Currently we just error out in this case, after
this change we will fall back to using OSS signing. (Fixes #2558)

Also adding a warning for a case where if both `strongName` and `keyFile`
settings are provided we would just display errors from Roslyn which might
be hard to understand/troubleshoot because the names used in the errors
are different from the names we use in project.json (Fixes #2452)
moozzyk pushed a commit that referenced this issue Oct 19, 2015
…eClr

If the project.json file contains the `keyFile` on CoreClr and Mono we
will extract the public key from the snk file and will OSS sign the
assembly with the extracted key. (Fixes #2558). We will do the same on
desktop CLR if the `keyFile` option is accompanied by `"useOssSigning": true`

As a result of this change the `keyFile` and the `useOssSigning` are
no longer mutually exclusive and we will no show cyptic Roslyn
compilation errors we would have shown before. (Fixes #2452).
moozzyk pushed a commit that referenced this issue Oct 20, 2015
…eClr

If the project.json file contains the `keyFile` on CoreClr and Mono we
will extract the public key from the snk file and will OSS sign the
assembly with the extracted key. (Fixes #2558). We will do the same on
desktop CLR if the `keyFile` option is accompanied by `"useOssSigning": true`

As a result of this change the `keyFile` and the `useOssSigning` are
no longer mutually exclusive and we will no show cyptic Roslyn
compilation errors we would have shown before. (Fixes #2452).
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants