Enhancement-238-StrongNameBinaries

18 views
Skip to first unread message

Linda Lawton

unread,
May 20, 2015, 2:56:07 AM5/20/15
to google-api-d...@googlegroups.com
In an attempt to keep everyone up to date, and get some feed back.

I am currently testing the following change(s).

1. Strong naming in binaries #238: https://github.com/google/google-api-dotnet-client/issues/238
2. Update zlib to the strong name version. (Should this have its own issue number?)


Before we can strong name sign our library I needed to contact(trackdown) the owners of Zlib.Portable https://www.nuget.org/packages/Zlib.Portable/, and request that they sign it. As you know everything must be signed for this to work.

A few weeks ago I managed to track them down on twitter they have created a beta version for us to test with. https://www.nuget.org/packages/Zlib.Portable.Signed/1.11.0-beta1

Status:

Over the weekend I added the zlib library to a fork of the Google .net client library, and signed all of the dlls. The branch can be found here https://github.com/LindaLawton/google-api-dotnet-client/tree/linda-Enhancement-238-StrongNameBinaries


What needs to be done before this can be merged:

1. Test that the signed version of zlib works. Once I can verify this I have been told by the developers that they will release it. They are just waiting for someone to say its working.

a. My plan is to create a project and test zlib 1.11 on its own. We don't need to verify that it works with our project at this stage. I just need to tell them that its working and they will release it.

2. Add the final release of zlib 1.11 to the Google .net client library.

3. Test that zlib works with the client library this time.

4. Test that the dlls are still stable and we are able to access Google APIs.


The library appears to build and create the dlls. I have not been able to go more into it then that, due to time constraints. I have tried to create a project using them, but have been running into some problems with miss matching dlls in Google.Apis.Auth.PlatformServices. I even tried using the email scope which doesn't require any of the discovery api dlls, so should have avoided any dependency issues.

I suspect that I am mixing and matching different versions of the dll by mistake, I normally just grab the NuGet packages. It has been a long time since I have manually built the dlls and I am having a hard time remember how I did it last time.

I will update this thread as I have more information for you. Again comments, concerns, and constrictive criticism are all welcome.

Linda





Reply all
Reply to author
Forward
0 new messages