These are chat archives for Humanizr/Humanizer

4th
Feb 2016
Oren Novotny
@onovotny
Feb 04 2016 01:42
@jnm2: What exactly is the issue - when you install packages, how do you have NuGet configured? lowest dependency version or highest?
choosing higher versions of dependencies aren't gauranteed to be supported on your platform for any package
it's like saying version 1.0 of foo supports .net 4, version 1.1 dropped support of .net for and requires at lest .net 4.5
and library b takes a dependency on 1.0
Joseph Musser
@jnm2
Feb 04 2016 01:45
It's however it's configured out of the box. I think lowest. The issue is that I don't need and should not have .NET Core dependencies in 4.5.2 desktop project.
Oren Novotny
@onovotny
Feb 04 2016 01:45
you do if you use project.json for it
and you can
project.json is not limited to net46 or .net core projects
Joseph Musser
@jnm2
Feb 04 2016 01:46
I don't believe project.json is an option for my company.
Oren Novotny
@onovotny
Feb 04 2016 01:46
I can try to add blank dependency groups in the next minor release as a stop-gap measure
but the package does install on 4.5.2
system.runtime 4.0.20 will NOT
Joseph Musser
@jnm2
Feb 04 2016 01:46
This is a standard 4.5.2 csproj. Humanizer 1.37.7 worked perfectly.
Oren Novotny
@onovotny
Feb 04 2016 01:46
but this doesn't depend on that
it's system.runtime 4.0.0
and the dependency resolution depends on how nuget is configured by default
out of the box, it's lowest patch
Joseph Musser
@jnm2
Feb 04 2016 01:48
Anyhow, since I don't need the .NET 5 dependencies I'd like the clutter out of the way. In addition, NuGet assumes that they are out of date and tries to upgrade them, failing because I'm not on 5.
Oren Novotny
@onovotny
Feb 04 2016 01:48
that's a nuget issue
question is can you install the package as-is
or is it an upgrade issue for the dependent packages?
Joseph Musser
@jnm2
Feb 04 2016 01:49
I can, but it's a major annoyance. what was wrong with the way 1.37 did it?
Oren Novotny
@onovotny
Feb 04 2016 01:49
1.37 did not support .net core
or the dotnet tfm
Joseph Musser
@jnm2
Feb 04 2016 01:49
Ah, so that's what's happening
Oren Novotny
@onovotny
Feb 04 2016 01:49
using the dotnet TFM means specifying dependencies too
so the real issue is that the NuGet client is unable to filter available upgrades based on compatibiltiy
that's something they can't easily do today but will be able to do with the upcoming netstandard TFM which aims to clean up the mess of dotnet
Joseph Musser
@jnm2
Feb 04 2016 01:51
Until netstandard is available, I thought these blanking workarounds were the expected workaround.
Oren Novotny
@onovotny
Feb 04 2016 01:51
note that you'll still have the same issue
because this package would be netstandard1.1
and that is compat with .net 4.5.2
and so will it have to specify its dependencies
the later system.runtime will be netstandard1.4 and thus not compatible with 4.5.2
so different tfm but the NuGet client may have the opportunity to filter packages that aren't compatible moreso than it can do today
Joseph Musser
@jnm2
Feb 04 2016 01:53
Until NuGet refines the process, can you please blank the dependencies for desktop .NET?
Oren Novotny
@onovotny
Feb 04 2016 01:53
it's not just desktop btw
its any "system.runtime" compat projects, i.e., almost all of them
Joseph Musser
@jnm2
Feb 04 2016 01:54
Okay, that sounds familiar.
Oren Novotny
@onovotny
Feb 04 2016 01:54
the idea of dotnet and netstandard is to get packages out of the platform business
so they shouldn't be targetting platform specific tfms if they don't have to
I would recommend filing a bug on the NuGet site about this though and feel free to @ me on it
I agree that it's confusing and messy
Joseph Musser
@jnm2
Feb 04 2016 01:55
So I'm sure I'm not the only one irritated by this. In the meantime, how hard is it to do what others have done and simply blank out dependencies on all the other platforms?
Oren Novotny
@onovotny
Feb 04 2016 01:56
I can do that for now, a PR could help get it started though :)
I've been slammed at work this week
Joseph Musser
@jnm2
Feb 04 2016 01:57
Got it. I would do it in a heartbeat if I was at all confident in my understanding of the mechanics involved.
I'm also not sure I totally understand what I need to put in the NuGet issue. It seems like this is already being discussed here: https://github.com/dotnet/corefx/issues/4367#issuecomment-154911230
Oren Novotny
@onovotny
Feb 04 2016 02:07
the issue you're having is in the NuGet client
not corefx
the TFM's work as designed
the general issue is that a newer version of a package may not be backwards compatible with an older framework
and it shows as an upgrade in NuGet
that should be filtered
the compicating factor is that platform secific TFM > dotnet > portable-
so that if there's a blank dependency group and something like UWP (uap10.0) needs those dependencies, it won't be there
because uap10.0 falls back to win8 which is > than dotnet if present
so you'd need to have blank depenency groups for one band of versions and then duplicate the orig dependencies for a higher ver
all of which is a maintanance nightmare on the package that this is all meant to avoid
long way of saying that this is really a UI bug in NuGet :)
not corefx or the tfm's
Joseph Musser
@jnm2
Feb 04 2016 02:12
So even when everything is fixed, I should get used to having ten extraneous packages sitting in packages.config that do absolutely nothing in my companies 4.x projects?
Oren Novotny
@onovotny
Feb 04 2016 02:12
yup
or switch to project.json for those
much easier
Joseph Musser
@jnm2
Feb 04 2016 02:12
Interesting.
Oren Novotny
@onovotny
Feb 04 2016 02:12
a .net 452 project can use it
and you get transitive references and a lot more
Joseph Musser
@jnm2
Feb 04 2016 02:13
Including winforms and wpf?
Oren Novotny
@onovotny
Feb 04 2016 02:13
yes
Joseph Musser
@jnm2
Feb 04 2016 02:13
Oh apparently
Joseph Musser
@jnm2
Feb 04 2016 02:13
I may have to push for this
Oren Novotny
@onovotny
Feb 04 2016 02:13
the key bit is that you need the frameworks to be net452 in your case
and the runtimes should be "win"
lastly because the tools don't do this for you yet, you need this in your exe and unit test projects: https://github.com/onovotny/Zeroconf/blob/master/ZeroconfTest.NetFx/ZeroconfTest.NetFx.csproj#L16
that' ensures the referenced libs are copied to the output dir as the default is false
which makes building libraries not put a hundred copies of every ref in each dir
so you put the project.json in there, delete packages.config, unload the project and remove the references items that nuget added (and also any targets/props that nuget added)
Joseph Musser
@jnm2
Feb 04 2016 02:15
I'm not sure I properly appreciate the new landscape here yet.
Oren Novotny
@onovotny
Feb 04 2016 02:15
then in your CI build, you call nuget restore on your sln
there's a lot to take in, I do need to blog this specifically
Joseph Musser
@jnm2
Feb 04 2016 02:16
That would be awesome.
Oren Novotny
@onovotny
Feb 04 2016 02:16
your gitignore should have *.lock.json, *.nuget.targets and *.nuget.props as those files should not be checked in
Joseph Musser
@jnm2
Feb 04 2016 02:17
Being slammed at work myself is not conducive to picking up .NET Core tech-related stuff.
Oren Novotny
@onovotny
Feb 04 2016 02:17
my motivation here was for xamarin forms pain
because xam forms pulls in a lot and upgrading it was painful
here I upgrade a single package
and the dependencies follow
and without any changes to the csproj so merging that is less of an issue
Joseph Musser
@jnm2
Feb 04 2016 02:18
That's something to be excited about. Forgot about that benefit.
All the information I find about project.json assumes ASP.NET. Is it fully supported in Visual Studio for every project type, so I won't regret moving?
Oren Novotny
@onovotny
Feb 04 2016 02:20
yes*
except that packages that rely on /content stuff need to be updated to use the new /contentFiles mechansm
Joseph Musser
@jnm2
Feb 04 2016 02:28
Thanks for the tips. I appreciate what you're doing.