Strong naming in binaries

[GoogleCodeExporter]

Could the pre-build binaries being distributed be signed?

If I want to add Google API to my signed assemblies it needs to be signed as 
well.

Dependencies, like Newtonsoft.Json, then need to be signed too.
(Newtonsoft.Json has a strong-named version available from NuGet)

Original issue reported on code.google.com by atre...@gmail.com on 12 Aug 2012 at 6:14

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I would also appreciate, if the pre-build binaries would be signed.

Until then you have to build them on your own...
HOWTO(HOWIDID):
1. Download latest source files from Google.
2. Open Solution 'GoogleApisClient' in Visual Studio.
3. Sign the projects you need (Properties->Signing) with a generated keyfile.
   (I have signed every project in solution with the same key)
4. Provide public key to friend projects (AssemblyInfo.cs).
4.1. Getting public key: 
   + Extract public key with 'sn.exe' from projects key file (VS prompt: sn.exe -p <MyKey>.snk <MyKey>.pub
   + Now get the bytes from <MyKey>.pub as hexstring(!) (e.g.: hexdump -e '"%02x"' <MyKey>.pub) and copy them to the 'InternalsVisibleTo(...)' lines in the assembly info (e.g.: [assembly: InternalsVisibleTo("Google.Apis.Tests, PublicKey=<hexstring>")])
5. TRY TO BUILD
5.1. If it succeeds - skip to [6]
5.2. If Not - download signed versions or build them from source (if available) 
of third-party libs and reference them in the google projects.
6. Reference newly built libs in your assembly.
7. Try to build your signed assembly - it should work now!

Original comment by develope...@gmail.com on 28 Aug 2012 at 5:35

[GoogleCodeExporter]

Original comment by davidwat...@google.com on 12 Sep 2012 at 5:30

• Changed state: Accepted
• Added labels: Priority-Medium, Type-Enhancement, Usability

[GoogleCodeExporter]

I am creating an SSIS component which must be GAC'd.  The component and its 
referenced assemblies must be strong named.  The fact that the google api 
binaries are not strong named is a big headache.

Original comment by richard....@gmail.com on 21 Mar 2013 at 6:05

[GoogleCodeExporter]

rather than having to use hexdump.exe, you can use sn.exe to output the 
PublicKey value.

sn.exe -tp mykey.pub >mykey.txt

Original comment by richard....@gmail.com on 22 Mar 2013 at 12:22

[GoogleCodeExporter]

Issue 212 has been merged into this issue.

Original comment by pele...@google.com on 24 Apr 2013 at 9:58

[GoogleCodeExporter]

I am creating a SSIS connection manager and need strong named dll's.  But have 
run into a problem when adding the strong names myself.

When strong naming both Google.Apis.dll and 
Google.Apis.Authentication.OAuth2.dll
and adding them into a project (add reference) an error occurs about missing 
assembly reference Google.Apis.Authentication.Iauthenticator. When adding the 
weak named Google.Apis the error disappears.   But Again they need to be strong 
named to add them to GAC.  Anyone know of a fix?

Original comment by laurl...@gmail.com on 13 May 2013 at 12:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

You will need the source of Google.Apis.Authentication.OAuth2.dll and recompile 
it with a strongly named version of Google.Apis.dll.

Original comment by escf...@gmail.com on 15 May 2013 at 4:44

[GoogleCodeExporter]

Following changes need to be implemented:
1. Replace the current Newtonsoft.Json.dll (.NET 3.5) with a strong named 
version.
2. Modify the assembly infos of all existing projects, so they are strong named.
3. Modify the code generator to produce strong named service assemblies 
(modifiy void CompileIntoLibrary(..) in Generator.cs in the 
GoogleApis.Tools.ServiceGenerator project)

I would like to provide a patch but never did this before so I dont't know how 
to + still need to resolve the following:

Locally everything is already implemented and seems to be working perfect for 
me. But when using the new strong named Newtonsoft.Json.dll together with the 
Google projects I get the following build errors (german version):
google-api-dotnet-client\Src\GoogleApis\Apis\Discovery\Schema\FutureJsonSchema.c
s(84,13): Fehler CS0103: Der Name "Identity" ist im aktuellen Kontext nicht 
vorhanden.
google-api-dotnet-client\Src\GoogleApis\Apis\Discovery\Schema\FutureJsonSchema.c
s(84,31): Fehler CS1061: "Newtonsoft.Json.Schema.JsonSchema" enthält keine 
Definition für "Identity", und es konnte keine Erweiterungsmethode "Identity" 
gefunden werden, die ein erstes Argument vom Typ 
"Newtonsoft.Json.Schema.JsonSchema" akzeptiert. (Fehlt eine Using-Direktive 
oder ein Assemblyverweis?)
google-api-dotnet-client\Src\GoogleApis\Apis\Discovery\Schema\FutureJsonSchema.c
s(92,13): Fehler CS0103: Der Name "Options" ist im aktuellen Kontext nicht 
vorhanden.
google-api-dotnet-client\Src\GoogleApis\Apis\Discovery\Schema\FutureJsonSchema.c
s(92,30): Fehler CS1061: "Newtonsoft.Json.Schema.JsonSchema" enthält keine 
Definition für "Options", und es konnte keine Erweiterungsmethode "Options" 
gefunden werden, die ein erstes Argument vom Typ 
"Newtonsoft.Json.Schema.JsonSchema" akzeptiert. (Fehlt eine Using-Direktive 
oder ein Assemblyverweis?)

As a first workaround I commented the two lines producing the errors and 
everything seems to work as expected - but I do not have a good feeling about 
that. Maybe someone sticking somewhat deeper in the project could shed some 
light on this.

Also currently I use a key of my own for signing the asemblies.
The following assemblies needed to be strong named + signed for me:
- Google.Apis.Authentication.OAuth2.dll
- Google.Apis.dll 
- Newtonsoft.Json.dll for .NET 3.5 (I rebuild this from the original Newtonsoft 
sources)
- (optional) all the ones created from the Google Service Repository like e.g. 
Google.Apis.Tasks.v1.dll and so on.

Regarding signing:
Checking in the key would be nonsense as anybody could (re-)sign anything with 
it. So signing would still have to be done by each dev on its own with its own 
key.

The first solution coming to my mind would be to implement a build switch into 
all assembly.info files (and/or implementing a global assembly file) for the 
solution and add additional "keyfile" and/or "keyname" command line switches 
for the service generator. 
Another solution would be to implement the signing but don't checkin the key 
into the sources + provide a meaningful error/help message when trying to build 
without providing a key file. Both solutions have advantages and disadvantages 
- maybe someone has a better idea how to solve this.

Thanks for attention.

Advice + Comments please ...

Original comment by thomas.a...@gmail.com on 16 May 2013 at 1:06

[GoogleCodeExporter]

Okay - I suddenly learned how to read :-P

I registered for code submissions, started a clone and try to provide a patch 
... 
Let's see if I am able to get things done the right way ...

But I still need help with the build error from above. So if someone could 
explain to me what is going on under the hoods ... ?

Original comment by thomas.a...@gmail.com on 16 May 2013 at 2:14

[GoogleCodeExporter]

Here are the strongly named assemblies I use 
(https://dl.dropboxusercontent.com/u/3121767/Strong.rar). In case of assembly 
manifest error check 
http://stackoverflow.com/questions/15679577/another-assembly-referencing-the-old
-dll.

Original comment by escf...@gmail.com on 16 May 2013 at 4:21

[GoogleCodeExporter]

FYI: 
I made a clone and implemented the changes needed for building strong named 
assemblies as well as the weak named ones. Also the generated assemblies can be 
strong named now with additional --keyfile and --keyname SourceGenerator 
command line options.

Sources available at: 
http://code.google.com/r/thomasalexanderboll-issue238-strongname/
!!! The code has not been reviewed yet and currently has at least one 
questionable change it it - do not use it - just for info in case anybody wants 
to contribute (your're welcome). You have been warned. !!!

For understanding what has been changed, quickest is to read these comments:
http://code.google.com/r/thomasalexanderboll-issue238-strongname/source/detail?r
=fead2cf8b1814202b52db6e8948e8fe2e15aff7e

I made a pull request and am awaiting the answer now.

Original comment by thomas.a...@gmail.com on 20 May 2013 at 11:12

[GoogleCodeExporter]

Hi Thomas, thanks for this change.
Before I'll review it, you should sign the contributor license agreement which 
is available here - 
https://code.google.com/p/google-api-dotnet-client/wiki/BecomingAContributor. 
Please update me, after you do so, so I'll start the process of reviewing your 
code.
Thanks again!

Original comment by pele...@google.com on 20 May 2013 at 12:53

[GoogleCodeExporter]

I pushed some additional changes to the clone and electronically signed the 
contributor license agreement.
So it should now be ready for a code review.

Feel free to change/comment on anything you like. If you have questions best 
contact me by email.

Regards,
Thomas
me. ['mi: dɒt']

Original comment by thomas.a...@gmail.com on 25 May 2013 at 7:57

[GoogleCodeExporter]

I need assemblies with strong name too, is there any status changes on this 
one?.
Anyone having compiled assemblies with strong naming that can share?
It seams that you need vs2012 to compile, and I don't have it.
I tried vs2012 express but says (after some installation issues) that the 
project "GoogleApis" is incompatible.

Original comment by octa...@realtimesites.com on 5 Sep 2013 at 8:33

[GoogleCodeExporter]

If someone is interested on having binaries with strong name, you can take a 
look at the changes in repo: https://bitbucket.org/ORC/google-api-dotnet-client

Be warn about Zlib.Portable I used myself signed version of that library 
because there is not a official signed release.

Original comment by octa...@realtimesites.com on 13 Sep 2013 at 4:11

[GoogleCodeExporter]

Is Google going out of their way to cause ASP.net developers grief?

Why wouldn't you sign them? 

What do you get out of not signing them? Assuming you're not a sadist, that is?

sincerely, frustrated here

Original comment by snetsp...@gmail.com on 5 Jul 2014 at 10:45

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Can we please get this looked at?

Error   1   Assembly generation failed -- Referenced assembly 'Google.Apis' does 
not have a strong name  Extension
Error   2   Assembly generation failed -- Referenced assembly 'Google.Apis.Core' 
does not have a strong name Extension
Error   3   Assembly generation failed -- Referenced assembly 
'Google.Apis.Auth.PlatformServices' does not have a strong name Extension
Error   4   Assembly generation failed -- Referenced assembly 
'Google.Apis.PlatformServices' does not have a strong name  Extension
Error   5   Assembly generation failed -- Referenced assembly 'Google.Apis.Auth' 
does not have a strong name Extension

Original comment by laurl...@gmail.com on 30 Jul 2014 at 1:06

[GoogleCodeExporter]

I got the source code for the latest Google.Apis, Google.Apis.Core and 
Google.Apis.Auth.dll and compiled them with strong name. Now when I compile my 
code using the strong name dlls it gives an error:
----------
The type 'Google.Apis.Services.BaseClientService.Initializer' is defined in an 
assembly that is not referenced. You must add a reference to assembly 
'Google.Apis, Version=1.9.0.23042, Culture=neutral, PublicKeyToken=null'
----------

in the line: UserCredential credential = new UserCredential(flow, "me", token);

Everything works just fine without strong name. I need to add the strong name 
because my main program where this library is referred has strong name.

Any ideas?

Original comment by skdu...@gmail.com on 31 Oct 2014 at 11:49

[GoogleCodeExporter]

I really can't grasp why a technological company like Google doesn't release 
strongly named assemblies in a 2-year timespan... Unbelievable.

Original comment by seto...@gmail.com on 27 Nov 2014 at 8:20

[GoogleCodeExporter]

Strong names end up a versioning nightmare for code reuse. There are wise 
reasons to not use strong names.

Original comment by jfb1...@gmail.com on 7 Feb 2015 at 8:51

[GoogleCodeExporter]

And if you want to compile it to a dll you cant if it isn't strong named 

Original comment by laurl...@gmail.com on 7 Feb 2015 at 8:56

[GoogleCodeExporter]

The last two comments are ridiculous.  Most libraries are strong named.  If
you want to use it with a custom SSIS component, it has to be strong
named.  I've personally compiled this to a single dll, strong naming it and
using ilrepack.  It's just something that should be built into the project
rather than forcing everyone through the same lengthy exercise.

On Sat, Feb 7, 2015 at 3:56 PM, <google-api-dotnet-client@googlecode.com>
wrote:

Original comment by richard....@gmail.com on 7 Feb 2015 at 9:22

[GoogleCodeExporter]

I have tried to create strong named dlls, but I am getting the following error 
when I try and build with the strong named dlls.
The base class or interface 'System.Object' in assembly 'System.Runtime, 
Version=2.6.9.0m Culture=neutralm PublicKeyToken=b03f5f7f11d50a3a' referenced 
by tyep Google.Apis.Services.BaseClientService' could not be resolved

Original comment by linda.br...@gdev.intilecta.com on 10 Feb 2015 at 3:42

[GoogleCodeExporter]

I could be wrong but...
by experience, the problem is within zlibportable. If someone can strong name 
sign that project and re-ship it through nuget, it should allow the google 
client library to be strong named signed. Then Google will need to sign its 
google api assemblies (Drive, calendar, tasks, etc).

On that note, if you look at issue #1 for zlib portable... 
https://github.com/advancedrei/Zlib.Portable/issues/1

We might have to fork the repository and re-package it for nuget if we want to 
this unblocked in a "non hacky" way since advancerei doesn't seem to be 
supporting their package.

Original comment by fcoulo...@google.com on 10 Feb 2015 at 1:27

[GoogleCodeExporter]

This is a nightmare, the project I have been working in the last weeks will not 
compile because google assemblies are not strong named. There are some insane 
workarounds to this 

http://buffered.io/posts/net-fu-signing-an-unsigned-assembly-without-delay-signi
ng/

Original comment by vay...@gmail.com on 10 Feb 2015 at 7:50

[GoogleCodeExporter]

#27, maybe I'm wrong too, but I see few NuGet dependencies in 
google-api-dotnet-client, and they seem to be all signed:

DotNetOpenAuth.Ultimate.4.0.2.12119
log4net.2.0.0
Moq.4.0.10827
Newtonsoft.Json.4.5.4
NUnit.2.6.0.12054

#2's method still works, I just created a 'Google.snk' and signed all 
assemblies with it. The only readl trick is to figure out the public key from 
the SNK and use it for the InternalsVisibleTo attribute.

https://hanskindberg.wordpress.com/2012/04/17/get-publickey-from-snk-file-to-use
-for-internalsvisibleto/

The Google NuGet maintainers would have to create their own SNK and keep it 
private.

Using the library like this is somewhat of a drag of course, as you just want 
to use the NuGet package, and not worry about what branch/tag of the 
google-api-dotnet-client to compile.
That said, there ìs a 'NuGet' branch....

Original comment by atre...@gmail.com on 11 Feb 2015 at 8:27

[GoogleCodeExporter]

#27 You were right, I was building on the wrong branch (NuGet). Added strong 
naming to branch 1.9.1 required only ZLib.Portable to be signed.

Original comment by atre...@gmail.com on 12 Feb 2015 at 9:18

[GoogleCodeExporter]

Furthermore I contacted the publishers of the NuGet package and they seemed to 
be very willing to sign the assemblies, but were struggling for time.

I put a +1 at https://github.com/advancedrei/Zlib.Portable/issues/1, trying to 
get the dependent assemblies signed.

If that fails or takes to long, I guess that there should be other 
(portable)libraries that can be used for GZipping a stream, which are signed.

Original comment by atre...@gmail.com on 12 Feb 2015 at 9:28

[GoogleCodeExporter]

Same issue.  I've never run into this with all the other libraries I've used.  
In addition, the old google API is strong signed as it linked nicely into my 
code.

Original comment by sjohn...@netprof.us on 17 Feb 2015 at 11:40

[GoogleCodeExporter]

BTW, just because a DLL is signed doesn't mean the final app must be signed.  
However, the converse is true.  If the app needs to be signed, all libraries 
referenced must be signed.

Original comment by sjohn...@netprof.us on 18 Feb 2015 at 1:36