These are chat archives for Humanizr/Humanizer

8th
Feb 2016
Joseph Musser
@jnm2
Feb 08 2016 13:22
@onovotny Hey, you changed the title lol. I think Xamarin is a separate issue.
Us folks with 4.x are still going to wonder what to do with the NuGet UI bug and won't be looking for an issue titled specific to Xamarin.
Joseph Musser
@jnm2
Feb 08 2016 13:27
It seems to me you'd be the best person to file a bug report about the NuGet UI and represent the situation with the least misunderstandings. If I filed the bug and someone replied I'd basically have to come back to you.
I'm still reluctant to accept that PCL libraries should be visible in desktop .NET.
Oren Novotny
@onovotny
Feb 08 2016 15:13
I'll file a bug with the NuGet team. I also have a blog post coming later this morning that explains how to use project.json with any proj type which helps hide the transitive refs
Joseph Musser
@jnm2
Feb 08 2016 17:45
@onovotny I decided to follow your blog post (very nice) and uninstalled every nuget package and added the net452 win project.json template, reloaded the project and reinstalled the nuget packages. Having the packages in the references list is a much cooler experience.
But bad stuff happened.
I have 19949 compiler errors, all along the lines of "the type or namespace name 'Compression' does not exist in the namespace System.IO'; the type or namespace name 'NotifyCollectionChangedEventArgs' could not be found (are you missing a using directive or assembly reference), etc.
The type 'Component' is defined in an assembly that is not referenced. You must add a reference to assembly System, Version =4.0.0.0, etc (the reference is clearly there)
Joseph Musser
@jnm2
Feb 08 2016 17:51
project.json:
{
  "dependencies": {
    "Castle.Windsor": "3.3.0",
    "EntityFramework": "6.1.3",
    "Humanizer.Core": "2.0.1",
    "ncalc": "1.3.8",
    "Newtonsoft.Json": "8.0.2",
    "SharpDX.Direct2D1": "3.0.1"
  },
  "frameworks": {
    "net452": {}
  },
  "runtimes": {
    "win": {}
  }
}
Joseph Musser
@jnm2
Feb 08 2016 17:57
Also, Visual Studio freezes anywhere from 30-90 seconds as I navigate the NuGet UI on a very fast computer. That's new.
This message was deleted
This message was deleted
Joseph Musser
@jnm2
Feb 08 2016 18:05
Even more interesting, Castle.Windsor is the only package that actually causes the problem.
@onovotny So at this point, unless you can spot a configuration flaw on my part, Castle.Windsor is preventing me from using project.json which means I am not able to use Humanizer 2.0.1 without UI bugs.
If the project.json ecosystem is not ready for production yet across the board, it would still be really awesome to have a Humanizer package that doesn't require you to jump on board with project.json.
Oren Novotny
@onovotny
Feb 08 2016 18:11
does your project have references to system, etc?
Joseph Musser
@jnm2
Feb 08 2016 18:12
Yes.
Normal references, not NuGet references.
Being able to not reference System NuGet packages was the major reason to use project.json in the first place. Besides the UI bug.
Oren Novotny
@onovotny
Feb 08 2016 18:14
do you have a repro snippet?
I can create a blank 4.5.2 class lib with that project.json and it compiles...but it's not using any lib code in it yet
Joseph Musser
@jnm2
Feb 08 2016 18:15
Shall I upload a repro project?
Oren Novotny
@onovotny
Feb 08 2016 18:15
that would help
Joseph Musser
@jnm2
Feb 08 2016 18:15
Okay.
Does gitter allow uploads?
Oren Novotny
@onovotny
Feb 08 2016 18:16
dunno :)
you can try to drag/drop and see what happens
Joseph Musser
@jnm2
Feb 08 2016 18:18
Wow, don't even need to write code for this to break.
Drag/drop works
Steps: brand new 4.5.2 winforms app, add project.json template from your blog, unload/reload, install Castle.Windsor, instant errors
Might not be your problem. I can talk to Castle Windsor. But if that's the case and I'm stuck with packages.config I'm still unhappy about Humanizer and NuGet UI bugs. And a package that respects those bugs would be nice.
Oren Novotny
@onovotny
Feb 08 2016 18:23
You're getting hit by this bug in NuGet NuGet/Home#1880
castle windsor declares frameworkAssembly references and that's breaking NuGet
there is an open PR to fix it
Joseph Musser
@jnm2
Feb 08 2016 18:23
So the problem is on NuGet's end?
Oren Novotny
@onovotny
Feb 08 2016 18:23
looks like it's scheduled to be in NuGet 3.4
yes
it's incorrectly removing System.* references when a referenced package has them as frameworkAssembly
Joseph Musser
@jnm2
Feb 08 2016 18:25
Would you consider providing a non-buggy Humanizer package until the new ecosystem is production ready?
Oren Novotny
@onovotny
Feb 08 2016 18:25
there is a workaround <IncludeFrameworkReferencesFromNuGet>false</IncludeFrameworkReferencesFromNuGet>
put that in your csproj
when I put that in your sample, it fixed it
Joseph Musser
@jnm2
Feb 08 2016 18:26
Will do. I suppose when NuGet 3.4 rtms, I can/should remove the line?
Oren Novotny
@onovotny
Feb 08 2016 18:26
yep
Joseph Musser
@jnm2
Feb 08 2016 18:27
I love advances and all, but it would be nice to know that if a package is marked as stable it will just work on today's tech. Keeping track of what truly is and isn't stable can be time-consuming.
Oren Novotny
@onovotny
Feb 08 2016 18:28
honestly it does work today with packages.config
as is
Joseph Musser
@jnm2
Feb 08 2016 18:28
Except for the System.* upgrade messages. You're right, it does work. It's not seamless.
Oren Novotny
@onovotny
Feb 08 2016 18:29
yeah, agree but that can happen to any package
just happens that it's more prevelant on system
Joseph Musser
@jnm2
Feb 08 2016 18:31
It's a consideration, since System will happen every time.
I've never run into this before.
At least if you knowingly release a stable package that is guaranteed to trigger bugs whenever it is interacted with, the home page should probably explain that you need project.json and <IncludeFrameworkReferencesFromNuGet>false</IncludeFrameworkReferencesFromNuGet>.
Joseph Musser
@jnm2
Feb 08 2016 18:36
It'll save a lot of frustration and head scratching to have that documented. Or to just release packages under the constraints of what currently works properly with NuGet.
Oren Novotny
@onovotny
Feb 08 2016 18:37
project.json is an option but you certainly don't need it -- I can see about adding some explanation in the readme somewhere, but it boils down to the simple fact that not all package dependencies can/should always be upgraded. Packages specify one set; it's user-beware if you choose a newer one
as to the specific NuGet bug, from what I've heard from the NuGet team, most packages don't actually specify frameworkAssembly's so it's a small number of ppl that'd hit that
Joseph Musser
@jnm2
Feb 08 2016 18:38
You need it if you want to avoid buggy upgrade messages. Which most people probably would like to do.
Oren Novotny
@onovotny
Feb 08 2016 18:38
but I can add a known issues / workaround section
Joseph Musser
@jnm2
Feb 08 2016 18:39
:+1:
Oren Novotny
@onovotny
Feb 08 2016 18:39
happy to take a PR for that too if you'd like to write something up based on your experiences
Joseph Musser
@jnm2
Feb 08 2016 18:40
Where are you thinking, the https://github.com/Humanizr/Humanizer#install section?
Oren Novotny
@onovotny
Feb 08 2016 18:41
yeah, it can go into a sub-section under there
under specify languages but before features
Joseph Musser
@jnm2
Feb 08 2016 18:42
Just for my personal curiosity, what's wrong with taking the approach that Humanizer will respect the constraints of the packages.config NuGet bug until a fix is released? That'd be one of my top priorities.
Oren Novotny
@onovotny
Feb 08 2016 18:52
main issue is that all of this is by design and it's working as designed
the UI could/shoudl be filtering upgrades that may not apply but that's a new feature
and it's not limited to this one scenario
you could be referencing foo 1.0 and that provides support for .net45. then foo 1.2 comes out with support for net46 only
nothing is wrong with foo 1.0
and if package bar 1.0 depends on foo 1.0, that still works and will continue to work
Joseph Musser
@jnm2
Feb 08 2016 18:54
So this can happen within desktop? I do see it from your point of view then.
Oren Novotny
@onovotny
Feb 08 2016 18:54
yes
Joseph Musser
@jnm2
Feb 08 2016 18:54
is there a specific NuGet issue I can link to for the filtered upgrade feature?
Oren Novotny
@onovotny
Feb 08 2016 18:55
not yet, have not written it up yet
Joseph Musser
@jnm2
Feb 08 2016 18:55
Should I mention a specific version of NuGet, or simply call it "NuGet with packages.config"?
Oren Novotny
@onovotny
Feb 08 2016 18:57
it's anything
if you put system.runtime 4.0.0 into your project.json you'll get the same issue
Joseph Musser
@jnm2
Feb 08 2016 18:57
This incompatible upgrade problem also happens with project.json?
Oh.
Oren Novotny
@onovotny
Feb 08 2016 18:57
because NuGet will say "there's a newer version here"
even though it's not compatible
Joseph Musser
@jnm2
Feb 08 2016 18:57
So project.json circumvents it because it's not listed in the UI.
Oren Novotny
@onovotny
Feb 08 2016 18:57
yes
Joseph Musser
@jnm2
Feb 08 2016 18:58
And defaults lowest version.
Oren Novotny
@onovotny
Feb 08 2016 18:58
and by default it picks the lowest matching version
correct
lowest matching version among the graph of references
Joseph Musser
@jnm2
Feb 08 2016 18:58
So I should mention the lowest vs highest version setting because the other guy had that
Oren Novotny
@onovotny
Feb 08 2016 18:58
sure
lowest is the NuGet default but it's possible people change it
Joseph Musser
@jnm2
Feb 08 2016 18:58
I can see that, if they think newer = better
It often is
Oren Novotny
@onovotny
Feb 08 2016 18:59
if you have a win 8.1 project that pulls in system.runtime 4.0.10, then it'll unify to that min version
the converse, defaulting to latest, causes lots of pain in the NPM world
so there's no easy answer for defaulting
Joseph Musser
@jnm2
Feb 08 2016 18:59
Which maps 1:1 with reality :laughing:
Oren Novotny
@onovotny
Feb 08 2016 18:59
or rather, lowest ver seems to break less but now you have to deal with when to upgrade
Joseph Musser
@jnm2
Feb 08 2016 19:19
I'm not sure if I should mention the IncludeFrameworkReferencesFromNuGet issue.
It should be mentioned, but a better place to mention it is actually your blog post on how to migrate to project.json and what to expect.
It's only relevant to people that are interested in starting to use project.json; also, it makes your link so much more handy.
It was an awesome blog post btw.
Oren Novotny
@onovotny
Feb 08 2016 19:25
I'm updating that blog post to mention that
the post is updated now
Joseph Musser
@jnm2
Feb 08 2016 19:29
You are awesome and I do apologize for being so persistent about this.
Oren Novotny
@onovotny
Feb 08 2016 19:32
no worries, I do want to make sure people don't get blocked
I realize it's a big jump/model shift
Joseph Musser
@jnm2
Feb 08 2016 19:34
I'm currently attempting to finalize my first PR
I think the PR went to my fork instead of upstream
Also, GitHub keeps putting me on your dev branch and the forked dev branch. For documentation, what branch do you want me to use?
Oren Novotny
@onovotny
Feb 08 2016 19:39
generally dev to dev
but for this probably branch off of master and a PR to master
Joseph Musser
@jnm2
Feb 08 2016 19:40
:+1:
Humanizr/Humanizer#523
Did I do it right?
Joseph Musser
@jnm2
Feb 08 2016 19:49
I wish the NuGet UI would stop lagging when I search for packages. Never lagged before.
Packages install very quickly now though.
Joseph Musser
@jnm2
Feb 08 2016 20:07
Yay build server issues
Joseph Musser
@jnm2
Feb 08 2016 20:14
One class library project can't find EntityFramework. Builds fine locally. Not sure how to proceed.
Joseph Musser
@jnm2
Feb 08 2016 20:21
This message was deleted
Joseph Musser
@jnm2
Feb 08 2016 21:13
@onovotny Can you add one more bit of information to your blog post? If you are using TFS build, TFS 2015 Update 1 must also be installed. TFS 2015 no update alongside Visual Studio 2015 Update 1 on the build server isn't enough.
Didn't want to bug my boss but that's what solved my issue.