I have been working with the Google APIs .Net client library now since 2012 it was still in beta when I started using it. I have since then been wondering wishing I could track down the lead developer on the project and have a chat with him. Back in June I got my wish, actually he tracked me down. We started talking and he asked me for a favor. Deal with issue #238, he didn’t have the time.
For the last several months, I have been working closely with Eyal Peled the lead developer on the Google APIs .Net Client library. Our goal was to deal with issue #238. For those of you who do not know or are not nerdie enough to track the issues in the client library. Issue #238 was submitted 12 Aug 2012 and is entitled “Strong naming in binaries”.
I am copying this directly from the blog post announcing the release Announcing the release of 1.9.2
This release is special since we have several new contributors:
- Eric Koleda fixed Issue 548, batch requests used to fail if the response contains duplicate HTTP headers.
- Richie Foreman switched the ServiceAccountCredential signing to be FIPS compliant.
- Linda Lawton, who addressed Issue 238. From this release moving forward, all Google.Apis are signed! So, all the following StackOverflow issues: Google Directory API isn’t strong signed, Strong naming Google APIs and Where can I get the strong named version of Google .NET client library are history! Thanks Linda for all your help in solving this one, in cleaning the issue tracker, and in answering questions using the google-api-dotnet-client StackOverflow tag.
The reason I copied it directly yes that’s me! I am currently the only non Googler allowed to contribute to the Google APIs .Net Client library. How awesome is that!
What is a strong name binary?
The purpose of a strong name is solely to ensure that when you load an assembly by name, you are loading exactly the assembly you think you are loading. You say “I want to load Google APIs .NET client library, version 1.9.2, that came from Google”. The strong name gear ensures that you actually load precisely that DLL, and not another assembly called Google APIs .NET client library, version 1.9.2, that came from Dr. Evil Enterprises. You can then set security policy which says “if I have an assembly from Google on my machine, fully trust it.” These scenarios are the only by-design purposes of strong names.
The funny thing is I actually added my name to this issue way back in 2013 not long after I started working with the Google APIs I was hoping I could use the client library in my project. After a lot of research and hair, pulling out I found I could not use the client library because it wasn’t strong name signed. This forced me to access the Google APIs the hard way I had to code it all from the ground up.
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
In the end, I realize that I would have not been able to use the library even if it had been signed. My SSIS task supports .Net framework 3.5 the Google APIs .Net client library only supports .Net framework 4.0 and 4.5.
With release 1.9.2 of the Google APIs .Net client library it is now possible to add, the library to your .dll projects and add them to GAC.
You can also now verify that the .dll on your machine is in fact the one we have released and not some evil version of it. I will be looking into adding some documentation on how to verify the dlls but it will not be until after I get back from vacation.