[deleted comment]

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!

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.

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

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

Issue 212 has been merged into this issue.

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?

[deleted comment]

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

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 ...

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 ... ?

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.

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.

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!

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']

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.

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.

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

[deleted comment]

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

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?

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

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

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

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:

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

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.

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/

#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....

#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.

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.

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.

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.