Don't rely on StrongNameKeyPair

[atykhyy]

Improving on netstandard1.3, netstandard2.0 provides the type System.Reflection.StrongNameKeyPair, but on .NET Core it is merely a stub that throws PlatformNotSupportedException from all methods and properties. This pull request extends WriterParameters with two new properties for strong name key blob and strong name key container, using them in preference to StrongNameKeyPair when set, ports a couple of crypto routines from Mono, and marks WriterParameters.StrongNameKeyPair as obsolete as it is not usable on .NET Core. The code in this PR has been in use on .NET Core 2.0.

[SimonCropp]

nice :)

[SimonCropp]

@jbevain thoughts on this one? want me to rebase it?

[jbevain]

@SimonCropp yeah I like it, I think it should go in 0.11.

[pcshrosbree]

Is any work happening on this? Or is another approach recommended?

[ADD-Juan-Perez]

@jbevain When do you plan to publish '0.11' version with this change?

[clairernovotny]

Are there any docs on how to use this? I'm trying to stumble my way through this. Even sample code that shows its use...

[atykhyy]

When you want to write a strong-named module in a portable manner, put either the content of the .snk file as byte[] into writerParameters.StrongNameKeyBlob or the name of the key container into writerParameters.StrongNameKeyContainer and pass those writerParameters to the module/assembly writer method. That's all there is to it.

[clairernovotny]

Do we need to also still set assembly.Name.HasPublicKey and assembly.Name.PublicKey?

Also would be good to update the wiki: https://github.com/jbevain/cecil/wiki/StrongName

assembly.Name.PublicKey is a byte[], but I couldn't find any external way to get that public key from a snk. I had to copy/paste code from this PR to do it. Is there a public method to get the public key from an snk that is available (or could be exposed)? I had to copy the GetPublicKey from // https://github.com/atykhyy/cecil/blob/291a779d473e9c88e597e2c9f86e47e23b49be1e/Mono.Security.Cryptography/CryptoService.cs and CryptoConvert to get the RSA from the snk.

[clairernovotny]

FWIW, this came up in my PR here for StrongNamer while adding support for .NET Core: dsplaisted/strongnamer#41. You can see the files I had to add/code I had to copy.

[jbevain]

@onovotny the PublicKey will be computed from the pair if you pass a set of pair to the parameters:

cecil/Mono.Cecil/AssemblyWriter.cs

Line 106 in 12da1bf

name.PublicKey = CryptoService.GetPublicKey (parameters);

[clairernovotny]

@jbevain thanks. Is there an API to get the public key from an snk if I need it for something else? In the PR, I need to get the full public key in .NET Core so that it can rewrite the InternalsVisibleTo attribute. If there's an API for that, I wouldn't have to duplicate any of the code from here.

[jbevain]

@onovotny not that I know of. You should be able to extract what you need from CryptoService.cs and CryptoConvert.cs without too much troubles.

[SimonCropp]

i have this is the fody fork of cecil Fody@e541e2b

[clairernovotny]

@SimonCropp it would be useful to have that directly in Cecil. @jbevain I do have the code copied, but given that .NET Core has no other way to deal with this data structure, it speaks to a need for it elsewhere.

[SimonCropp]

it would be useful to have that directly in Cecil

shoudnt that code exist in netcore and not cecil?

[clairernovotny]

Probably, but Microsoft doesn't seem to care about supporting anything to do with Strong Names in .NET Core. It's explicitly all PNSE's. Any support will have to come externally.

[SimonCropp]

agreed. happy for someone to take the code and merge into cecil, if @jbevain is ok with that. i wont have the capacity in the short term

[Zastai]

Also would be good to update the wiki: https://github.com/jbevain/cecil/wiki/StrongName

I second this - I came here to report the StrongNameKeyPair approach being broken, because nothing pointed me at the new properties.

[Zastai]

Also note that using any non-null value for StrongNameKeyContainer currently results in a strong named assembly; if there is no matching container, a random (or default; not entirely sure now) key pair gets used. So you get no error, but a potentially unusable assembly (due to wrong public key).