Originally reported on Google Code with ID 13
There are various reasons for strong-naming an assembly. These include:
* Only strong-named assemblies can be put into the GAC.
* Strong-named assemblies can only reference other strong-named assmeblies.
* Strong-named assemblies are uniquely identifiable by key, name and version and can
be verified as not having been tampered with.
In our scenario, we needed to make our core application signed, which requires that
all third party DLLs are also signed. The ildasm/ilasm workaround for retro-signing
does not work for or-tools DLLs likely due to the unusual linking process.
I've modified Makefile.csharp.mk to consider the variables CLR_KEYFILE and CLR_DELAYSIGN
which can be passed as arguments to make. Specifying CLR_KEYFILE (and optionally CLR_DELAYSIGN)
will produce signed DLLs and test executables. A diff against r2200 is attached.
Reported by tomg@zanyants.com on 2012-09-05 11:17:09
- _Attachment: [diff.txt](https://storage.googleapis.com/google-code-attachments/or-tools/issue-13/comment-0/diff.txt)_
Originally reported on Google Code with ID 13
Reported by
tomg@zanyants.comon 2012-09-05 11:17:09- _Attachment: [diff.txt](https://storage.googleapis.com/google-code-attachments/or-tools/issue-13/comment-0/diff.txt)_