-
Notifications
You must be signed in to change notification settings - Fork 965
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
Comments
Seems borked for Xamarin as well.
VS2015, latest (stable) version of Xamarin and NuGet and all that. You can see this on https://www.nuget.org/packages/humanizer.core
|
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 |
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 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. |
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. |
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. |
@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. |
@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. |
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. |
@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. |
@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? |
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 |
The Xamarin issue is now fixed with a workaround in 2.0.1 which is live on NuGet now. |
This post might be helpful for reducing the friction of transitive dependencies: |
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:
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 includenet
.The text was updated successfully, but these errors were encountered: