1

Closed

Ambiguous Portable Libraries Should Prompt User

description

When referencing a package that contains a portable library, such as "portable-windows8+net45", and an ambiguous non-portable library, such as "net45", the user should be prompted as to which library they want to reference.

USE CASE:
A related work item (https://nuget.codeplex.com/workitem/2790) states that it should be up to the package developer to choose a preference, but that won't work in the following scenario because the correct choice is only known by the user, similarly to the discussion: https://nuget.codeplex.com/discussions/398564.
  1. User adds a new portable class library project to their solution.
  2. User adds a reference to a NuGet package that contains a "portable-windows8+net45" library and a "net45" library. A reference to the portable library is added automatically by NuGet.
  3. User adds a WPF project to their solution.
  4. User adds a reference from their WPF project to their portable class library project.
  5. User adds a reference in their WPF project to the previous NuGet package, only this time NuGet automatically chooses the "net45" library based on the rules defined in http://docs.nuget.org/docs/release-notes/nuget-2.1.
Given the choice, the package author is most likely going to give the "net45" library preference because it has a larger surface area, but clearly that's incorrect in this situation. The user needs to have the choice.
Closed Jan 3, 2013 at 10:32 PM by howarddierking
We absolutely don't want to prompt as this would end up creating a bad general case NuGet experience for the sake of what appears to be a single package (Newtonsoft.Json). As such, we're closing the issue.

comments

davedev wrote Dec 2, 2012 at 1:39 AM

Or perhaps there's a way to automate it so that NuGet can make a better decision based on project references. Though perhaps the easiest and safest solution would be to give the user a choice.

howarddierking wrote Dec 28, 2012 at 9:46 PM

Let's review this along with http://nuget.codeplex.com/workitem/2926

dsplaisted wrote Jan 3, 2013 at 4:13 PM

I think the perspective from the PCL team is that platform-specific versions of a library in a package should be compatible with the portable versions. So in the example above it would be fine to reference the net45 library from the the WPF project. The net45 version might have additional functionality over the portable version, but it wouldn't have anything missing, and something compiled against the portable version should work with the net45 version.

To me, this seems like an extension of how this should work for different versions of a platform. IE it's really the same situation as if you had a package with net40 and net45 libraries, a net40 library referencing the package, and a net45 WPF app referencing the net40 library and the package. NuGet would pick the net45 library for the app and it should be expected that it would work.

Json.NET unfortunately has an issue where the WP7 version isn't compatible with the portable version. This is because the portable version is signed with a strong name, but the WP7 version isn't. So it might be good to have a way to override the logic, but that should be the exception rather than the rule.

davkean wrote Jan 3, 2013 at 6:35 PM

Yes, I agree with Daniel, this would cause NuGet to start prompting for all of our packages (Microsoft.Bcl, Microsoft.Bcl.Async, Microsoft.Composition, Microsoft.Tpl.Dataflow, Microsoft.Bcl.Immutable + a few more in the works) - even though it does exactly what we expect and want today.

To play nicely multiple platforms, portable libraries should be API compatible with their platform-specific versions. ie I should be able to take a library built against the portable Json.NET, and run it on the desktop using the desktop version of Json.NET. If that doesn't work today, then I would consider it a bug on that library.

You don't want to have users to have to pick between using "portable" JSON.NET or using any extra functionality available in desktop JSON.NET. That's treating portable as a separate platform, not as as the platforms itself and is not a good user experience.