-
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 locale satellite assemblies #521
Comments
Hi @chriswill this change was done at the request of many users and captured in this issue thread: #59 The workaround if you don't want all of those packages is to either use Also, another approach is to use |
Thanks for the pointer to the thread. Was a shock to see this happen during the upgrade, but I can see your decision process. |
After reading this, I just spent half an hour manually removing all the locales that I don't use, one-by-one, by hand. VS only works on one NuGet package at a time. There should be clear instructions on installing only Humanizer.Core for only English support, or Humanizer for the full thing. Maybe renaming it to Humanizer.AllLocales will be clearer... There really should be a sign, in bold capital letters, saying "WARNING LARK'S VOMIT: A godzillion locale packages will be pulled in if you use this -- make sure this is what you want"... |
I updated my 1.37.7 to 2.0 through Nuget recently. First, I have a .Net 4.5.2 project and had the same question as issue #520.
But my question is about the locale satellite assemblies. I didn't choose to install them; they all came along. And it appears that they cannot be removed via Nuget once they are installed, even if you don't care about that locale.
The problem is that the huge number of installed locales really slows down the Nuget window. Operations like scrolling, checking for updates, etc. drag on forever once the locales became installed.
Since we cannot install or uninstall them individually, my opinion is that they should be in the same assembly/nuget download. That would take only one slot instead of the many that are installed today and wouldn't impact the Nuget window performance too much.
I know you probably have a vision where these can get updated independently on their own schedule, but from my perspective this isn't workable as you've currently implemented it.
I've dropped back to 1.37.7 until I can see the resolution for issue #520 and for this question.
The text was updated successfully, but these errors were encountered: