Skip to content
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

Humanizer.Core package does not install on Xamarin #520

Closed
jnm2 opened this issue Feb 1, 2016 · 13 comments
Closed

Humanizer.Core package does not install on Xamarin #520

jnm2 opened this issue Feb 1, 2016 · 13 comments

Comments

@jnm2
Copy link
Contributor

jnm2 commented Feb 1, 2016

I'm using Visual Studio 2015/NPM 3.3.0.167. When I install Humanizer.Core in a 4.5.2 project, it adds dependencies on these packages:

System.Diagnostics.Debug
System.Collections
System.Globalization
System.Linq
System.Reflection
System.Reflection.Extensions
System.Resources.ResourceManager
System.Runtime
System.Runtime.Extensions
System.Text.RegularExpressions

Previous releases of Humanizer did not do this. While these packages do not show up in references and build output, they are now in every project's packages.config and pulled by the build server. They also clutter the NuGet Package Manager interface.

Is there anything that can be done about this? 1.37.7's behavior was awesome.

Beyond being an annoyance, it causes an actual issue. It installs v4.0.0 of each package into the .NET 4.5.2 project, upon which NuGet immediately notifies you that each package is out of date. When you try to upgrade these .NET 5 packages, NuGet fails:

Could not install package 'System.Runtime 4.0.20'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.5.2', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

So if we use Humanizer v2, we are currently stuck with ten incorrect packages that are out of date and not upgradable, adding unwanted noise and erroneous alarms to NuGet package management for the consuming projects.

I'm not knowledgeable enough to be sure, but I'm guessing the problem is the targetFramework="dotnet" on the dependency group being wide enough to include net.

@taspeotis
Copy link

Seems borked for Xamarin as well.

Attempting to gather dependencies information for package 'Humanizer.Core.2.0.0' with respect to project 'XXX', targeting 'Xamarin.iOS,Version=v1.0'

...

Install failed. Rolling back...
Package 'System.Reflection.Extensions.4.0.0 : System.Reflection [4.0.0, ), System.Runtime [4.0.0, )' does not exist in project 'XXX'

...

Could not install package 'System.Reflection.Extensions 4.0.0'. You are trying to install this package into a project that targets 'Xamarin.iOS,Version=v1.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

VS2015, latest (stable) version of Xamarin and NuGet and all that. You can see this on https://www.nuget.org/packages/humanizer.core

Dependencies
DotNET 5.0
System.Diagnostics.Debug (>= 4.0.0)
System.Collections (>= 4.0.0)
System.Globalization (>= 4.0.0)
...

Humanizer.Core installed just fine into my PCL, however (.NET 4.5, Profile7)

@MatthewSteeples
Copy link
Contributor

I've had a go at creating a PR for it. Please have a look at #522 although it will need a push to NuGet

@clairernovotny
Copy link
Member

Thanks for this issue. These groups are by design to add support for dotnet CLI and project.json based build systems. Removing them breaks that support.

We do not need frameworkAssembly here, we really do need the dependencies. Please see my blog post for the detailed explanation:
https://oren.codes/2015/07/29/targeting-net-core/

These dependencies do install on .NET 4.5 and they're harmless. Trying to add empty dependency groups will cause issues down the road as specific TFM > dotnet > portable-*. These packages are the same reference assemblies that live on your computer used by the PCL project system but are now available to dotnet CLI and project.json.

To be clear, these references are NOT .NET 5 or .NET Core packages. They are the same reference assemblies that the "classic" PCL project system uses, just explicitly distributed via NuGet instead as more types of projects can use them not just in VS. Think VS Code, Linux, etc.

@clairernovotny
Copy link
Member

There is a bug in the System.Reflection.Extensions 4.0.0 package right now. I've bugged it here.

https://github.com/dotnet/corefx/issues/5955

I'll see what I can do about a temporary workaround in the package to unblock this until Microsoft fixes it.

@clairernovotny clairernovotny changed the title Why does the Humanizer.Core package install .NET 5 dependencies on a 4.5 project? Humanizer.Core package does not install on Xamarin Feb 7, 2016
clairernovotny pushed a commit that referenced this issue Feb 7, 2016
@MatthewSteeples
Copy link
Contributor

Thanks for the response Oren. It's not just Xamarin though; this package is failing to install for us on .net 4.5.1 because of the dependency on System.Reflection (not the Extensions one).

This resolves to version 4.0.10 (latest released) which doesn't have a net451 (or net45, net40 etc) folder, only a net46. This folder happens to be empty (suggesting it is there as a workaround).

I'm going to raise a bug for it on the corefx project, but not sure what the workaround for Humanizer is apart from the complex dependency pieces.

@clairernovotny
Copy link
Member

@MatthewSteeples How does System.Reflection resolve to 4.0.10? The specified version is 4.0.0. NuGet does not by default install a later version.

@MatthewSteeples
Copy link
Contributor

@onovotny It turns out I had VS set to resolve dependencies in "Highest" mode (and Humanizer.Core has a restriction of 4.0.0 or greater). Dropping that down to "Lowest" fixed my install issue.

@clairernovotny
Copy link
Member

Newer packages may drop support for older platforms, that's by design. If you look at the way the .NET packages and the .NET Platform Standard and all that assume that newer packages can support a wider surface area and thus not support all platforms.

@MatthewSteeples
Copy link
Contributor

@onovotny Yep, completely understand that. Surely that's an argument in favour of separating out the dependencies based on framework version though? Or are you saying that going forwards Humanizer is only going to support running on the latest version, unless the users of the library are willing to sift through which of the dependent packages can and can't be safely updated (which is what the original post by @jnm2 for this issue was talking about). The Xamarin issue (while still valid) is a separate issue.

@MatthewSteeples
Copy link
Contributor

@onovotny Or should we consider this a NuGet issue, and it shouldn't offer packages which don't match the frameworks you're currently targeting?

@clairernovotny
Copy link
Member

I think this is really a NuGet UI issue. It should be filtering out upgrades that are not compatible. There's no real possible way of splitting out the dependencies by framework version given the precedence of platform > dotnet/netstandard -> portable-

Some packages install on some platforms but not others. For example, that System.Reflection.Extensions package has extra binaries for .net core and windows 10, but it's not needed on net 4.5, wpa, wp etc. The lib dir has a _._ entry. That blank entry is missing Xamarin (or otherwise a lib\dotnet dir with a _._ default.

@clairernovotny
Copy link
Member

The Xamarin issue is now fixed with a workaround in 2.0.1 which is live on NuGet now.

@clairernovotny
Copy link
Member

This post might be helpful for reducing the friction of transitive dependencies:

https://oren.codes/2016/02/08/project-json-all-the-things/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants