search

kapil-chauhan-ngi / google-api-dotnet-client

Automatically exported from code.google.com/p/google-api-dotnet-client
Apache License 2.0
0 stars 0 forks source link

Cumbersome build procedure #354

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
1) The build procedure 
(https://code.google.com/p/google-api-dotnet-client/wiki/Build) is really 
cumbersome. Numerous and unclear dll dependencies, app.config, 
Microsoft.Bcl.Build.targets file, manual project file editing... Looks like a 
Linux compilation, not a normal .NET library.

2) Also the procedure is designed for a standalone app. In my case, there is a 
library that abstracts GDrive API and is used by the main app. In this library 
I don't have app.config, hence I need to put the binding redirects into the 
main app's app.config and that's not good.

Importing Microsoft.Bcl.Build.targets into the library's project gives the 
following warnings (while the main app's app.config has the required redirects):

  Consider app.config remapping of assembly "System.Runtime, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "1.5.11.0" [] to Version "2.5.19.0" [C:\Users\andy\projects\sic_windows\GDrive\Libs\System.Runtime.dll] to solve conflict and get rid of warning.
  Consider app.config remapping of assembly "System.Net.Http.Primitives, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "1.5.0.0" [] to Version "2.1.10.0" [C:\Users\andy\projects\sic_windows\GDrive\Libs\System.Net.Http.Primitives.dll] to solve conflict and get rid of warning.
  Consider app.config remapping of assembly "System.Net.Http, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "1.5.0.0" [] to Version "2.1.10.0" [C:\Users\andy\projects\sic_windows\GDrive\Libs\System.Net.Http.dll] to solve conflict and get rid of warning.
  Consider app.config remapping of assembly "System.Threading.Tasks, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "1.5.11.0" [] to Version "2.5.19.0" [C:\Users\andy\projects\sic_windows\GDrive\Libs\System.Threading.Tasks.dll] to solve conflict and get rid of warning.

Also adding a reference to System.Net (as recommended) produces the following 
compilation warnings:

warning CS1684: Reference to type 'System.Net.HttpWebRequest' claims it is 
defined in 'c:\Program Files (x86)\Reference 
Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Net.dll', but it could 
not be found
warning CS1684: Reference to type 'System.Net.WebResponse' claims it is defined 
in 'c:\Program Files (x86)\Reference 
Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Net.dll', but it could 
not be found
warning CS1684: Reference to type 'System.Net.WebRequest' claims it is defined 
in 'c:\Program Files (x86)\Reference 
Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Net.dll', but it could 
not be found

Original issue reported on code.google.com by ext.andr...@gmail.com on 11 Jul 2013 at 10:25

GoogleCodeExporter commented 9 years ago 
Did you try to use NuGet to handle your packages?
You will be surprise how easy it is when you use NuGet.

I'm aware that the procedure is a little bit complicated (even using NuGet) and 
we are working on providing a Google.Apis NuGet package.

Original comment by pele...@google.com on 14 Jul 2013 at 2:02

GoogleCodeExporter commented 9 years ago 
1) For now NuGet does not help much, because we need to do manual app.config 
editing anyway (and copying others libraries too). Hope it will change in the 
future.

2) Using Google Apis for a library (not a standalone app) is another issue. How 
do you suggest dealing with it (a library has no app.config)?

3) And the CS1684 warnings seem to be related to Issue 353: 
https://code.google.com/p/google-api-dotnet-client/issues/detail?id=353&colspec=
ID%20Type%20Component%20Status%20Priority%20Milestone%20Owner%20Summary

Original comment by ext.andr...@gmail.com on 14 Jul 2013 at 4:53

GoogleCodeExporter commented 9 years ago 
IMHO, making Google.Apis a Portable Class Library only complicates things for 
an average .NET developer (who often does not know/care about the portability 
and its cons/pros). It might be easier/cooler for the library maintenance, but 
not for using the library. Having separate builds for different .NET platforms 
is the most common practice in .NET community (e.g. at CodePlex).

Original comment by ext.andr...@gmail.com on 14 Jul 2013 at 8:07

GoogleCodeExporter commented 9 years ago 
1. You should not change app.config manually. NuGet does it for you. Notice 
that changing app,config is under "NOT using NuGet" section

2. You should advise your users to use NuGet as well, and it will do the magic 
for them.

3. I'm working on that, trying to figure out why it doesn't work for you guys

I don't agree with you, I think that PCL is awesome because it targets all the 
different platform. And it should be easy. I'm pretty sure that after we will 
understand why it doesn't work for you guys, and with a fix or two to the 
library it will easy to use again.

Keep in mind that providing NuGet package is in our roadmap, and actually we 
may prioritize it higher now, after we dealing with this issue with several of 
our users (not all of them, which is weird)

Original comment by pele...@google.com on 14 Jul 2013 at 3:04

GoogleCodeExporter commented 9 years ago

Original comment by pele...@google.com on 16 Jul 2013 at 2:57