-
Notifications
You must be signed in to change notification settings - Fork 526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix install for .NET 4.0 #716
Comments
Relevant: NuGet/Home#2084 |
The final option sounds like users would end up with two packages and potentially confusion. If I understand the middle option, that sounds good to me. |
I think there is a problem with 4.5 as well wild guess it doesn't its not installing PM> Install-Package Google.Apis.Analytics.v3 Gives error when you execute your application
PM> Install-Package Google.Apis.Analytics.v3 -Version 1.10.0.1210
Is there any way to do a code review or test the Nuget packages before a release? If memory servis this isn't the first time we have had issues with the packages. |
Will have a look myself. I don't think Microsoft.Net.Http should be needed, but I could be wrong. |
I created a new project in Visual Studio 2015 targeting .NET 4.5 and ran This simple program compiled and ran with no issue:
Were you trying this in the same project that had previously targeted .NET 4.0? Are there any binding redirects present in app.config? NuGet is unfortunately not as eager as it has to be about removing redirects when they are no longer necessary. |
This is a new project not related to my 4.0 projects i wanted to test pagination (Was hoping it was added). Project stats: Visual studio: 2013 |
It's working for me in a console app, VS2015, framework 4.5, using Storage (the API I'm most familiar with), listing buckets. Trying to find a laptop with VS2013 on... |
Let me see if i can recreate it. Something weird with this one project cant get it to do it again. |
I likewise can't reproduce the issue. I tried, in both VS2013 and VS2015:
Seemed to work fine in both environments. |
One option is to expand the generated library PCLs to target net40 again. However, when we build them we'll need to reference a PCL that also targets net40, so we'd have to build against 1.10. That means app.config binding redirects for everyone because, in the common case (net45+) the version we build against won't be the one that NuGet installs. Or we can add a new project specifically for net40 in every generated library. the PCL will remain as-is, i.e. targeting net45+. Of course, an extra project for every generated library is one of the things we were trying to avoid by dropping support for net40, but I really don't see a way out of it. 😞 |
Uninstall-Package Google.Apis.Analytics.v3 –RemoveDependencies seams to have fixed it. Might have been an issue with getting the packages the first time and it made a mess of things. |
Nope, that won't work either. What about customers who are writing net40+xyz PCLs? They'll be upgraded to something that they can't compile against. We need to have the old Profile328 target which will link against 1.10 and then a net45+xyz target that can link against 1.11. The |
TODO: Why isn't this taking effect? http://blog.nuget.org/20141001/targetframeworkfiltering.html |
If our packages contain two PCLs that are compatible with a given project, which will NuGet choose? |
Proposed fix: https://github.com/mmdriley/google-api-dotnet-client/tree/dotnet4-lite Specifically: https://github.com/mmdriley/google-api-dotnet-client/commit/65dfa2ec9e6f0574f525c9cff3f6a63382397897 My work is based on #713, so I'll wait until that's merged to put this out for review. Here's what this looks like installed in projects targeting Net40, Net45, and a few PCL profiles: mmdriley/PclTest@5d9faa6 |
Confirmed fixed in #718, now released as v1.12. Projects targeting .NET 4.0 will get up-to-date generated libraries and target an older version (1.10.0) of the generated libraries:
Projects targeting .NET 4.5 will get newer support libraries:
|
Shouldn't be back again. I've just checked that a dependency on Google.Apis.Calendar.v3 is possible in a .net 4.0 project. It correctly depended on Google.Apis v1.10.0 as expected. |
I wonder if he is trying to add each one by itself instead of just doing
If he is actually doing
It would of course tell him that it cant do that. |
Yes, good point, I've added a few comments on stackoverflow |
We removed support for .NET 4.0 in v1.11 (see #696). Our intent was that projects that still targeted .NET 4.0 would continue to see and install previous package versions that supported .NET 4.0.
Unfortunately, that's not the case. An attempt to install
Google.Apis.Storage.v1
in a project targeting .NET 4.0 today results in a compatibility error:The best workaround at the moment is for customers to install the previous version explicitly:
Install-Package Google.Apis.Storage.v1 -Version 1.10<tab>
(Unfortunately NuGet also won't do partial matching on the version.)
This isn't acceptable and it isn't the experience we intended to provide. We're sorry for the break.
I still want to limit the maintenance burden of .NET 4.0 support, for the reasons I described in my comment in #696. The install experience has to work, but I'm okay with it leaving customers at v1.10.
With that in mind, some options I can think of:
The text was updated successfully, but these errors were encountered: