NuGET Packagies
-
What do you guys think for these containers? After using them for a while with VS, I think this technology is a rubbish. Too many moving parts. Versioning nightmare. URLs changing, living you high and dry, conflicts between solution and projects etc. Is it just me who is not fully appreciate/understand this library management mechanic?
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
Somewhere a few days ago I posted "NuGet is a virus". ;) What particularly annoys me is:
Crap like that.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
Never used it. Worthless. Leave it for the cargo-cultists.
PIEBALDconsult wrote:
Never used it.
PIEBALDconsult wrote:
Worthless.
How would you know it is worthless, if you never used it? :sigh:
-
What do you guys think for these containers? After using them for a while with VS, I think this technology is a rubbish. Too many moving parts. Versioning nightmare. URLs changing, living you high and dry, conflicts between solution and projects etc. Is it just me who is not fully appreciate/understand this library management mechanic?
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
I like Nuget. We use it for everything in our shop. I can't convince you to like it. I can suggest you learn how to properly work with it, and I say this kindly, and not teasingly. If you have a team of 10 developers and only 2 know how to properly work with Nuget and keep things updated properly, then you are destined for failure, because the other 8 devs will elephant things up for sure. It does have its annoying problems, but they are manageable IMHO. Edit: we have our own Nuget repo (See JSOP's response) and we use this for most of our packages and for the same reasons that John mentioned.
-
What do you guys think for these containers? After using them for a while with VS, I think this technology is a rubbish. Too many moving parts. Versioning nightmare. URLs changing, living you high and dry, conflicts between solution and projects etc. Is it just me who is not fully appreciate/understand this library management mechanic?
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
I limit myself to the ones shipped by Microsoft. Ones like the UWP / WPF tool kits. No issues.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
I've had a few run-ins with NuGet during my career, but apart from one time, nothing I couldn't fix. What really bothers me is that it tells me to update to package v5.0.0, which I know to be built on .NET 5.0, while my project is .NET Core 3.1. That's not compatible, yet it wants me to update... X| It shouldn't be that difficult to recognize my .NET version and then only show me updates for that particular version, or so you'd think.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
To avoid version conflicts, create your own local NuGet repository and only install from that. That will keep NuGet from automagically "upgrading" your packages, and allow you more control over your upgrading process (upgrade only when you want to).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
What do you guys think for these containers? After using them for a while with VS, I think this technology is a rubbish. Too many moving parts. Versioning nightmare. URLs changing, living you high and dry, conflicts between solution and projects etc. Is it just me who is not fully appreciate/understand this library management mechanic?
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
+1 to avoid Nuget. It always was and is COMPROMISE to build process - you nerver be sure smth is not changed. And never sure what and when "it" will download. Definitely "school boys" who bring this sh****t to .NET (from Linux) didn't have enough qualification and enterprise development at all. Say "no" to drugs, say "no-no-never!!" to nuget. :)
-
Technology exists not to "being fixed", but to HELP development! If nuget has defect in working principles, I see no reason even mention this tool.
If technology could never be fixed we'd all be out of a job dead (probably) :~
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I've had a few run-ins with NuGet during my career, but apart from one time, nothing I couldn't fix. What really bothers me is that it tells me to update to package v5.0.0, which I know to be built on .NET 5.0, while my project is .NET Core 3.1. That's not compatible, yet it wants me to update... X| It shouldn't be that difficult to recognize my .NET version and then only show me updates for that particular version, or so you'd think.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
We just moved from 2.x to 5. Good luck when you get there, take booze!
veni bibi saltavi
-
We just moved from 2.x to 5. Good luck when you get there, take booze!
veni bibi saltavi
I'll skip 5 as it's not an LTS release. Although the move from 3.1 to 5 should be pretty painless... In theory :^) One of my customers, the only one with a software (1-man) team of their own, is on .NET 5 and so far it looks exactly like my 3.1 code :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
What do you guys think for these containers? After using them for a while with VS, I think this technology is a rubbish. Too many moving parts. Versioning nightmare. URLs changing, living you high and dry, conflicts between solution and projects etc. Is it just me who is not fully appreciate/understand this library management mechanic?
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
It's the worst dependency management option, apart from all of the other options. :) Jon Skeet wrote about some of the problems a while back: Versioning limitations in .NET | Jon Skeet's coding blog[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Don't you think it's WAY easier just to delete nuget and use normal libs in fixed folders???
Sure it is, but you can't argue the convenience of having the nuget packages to provide the libs and dependencies so you don't have to worry about getting everything manually. I was providing a solution that doesn't involve changing your processes with regards to NuGet packages.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Sure it is, but you can't argue the convenience of having the nuget packages to provide the libs and dependencies so you don't have to worry about getting everything manually. I was providing a solution that doesn't involve changing your processes with regards to NuGet packages.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013You mix all in one. Nuget is useful only in the way that every package has... info about dependencies! Period. I have no problem in getting all depended libs (esp. if reference contains info about homepage or binaries). Any commercial dev is a serious process (opposite to linux clowns who is ready to spend DAYS on hell knows what). There is no place for "guess what library is breaking the build!". Moreover: developer can intentionally keep old verion to keep compatibility with environment of clients (say, somebody still works in Win XP). That's why archaic 'nuget' is unacceptable. I agree only on one help: if I run util like `getrefs somepackage` and it downloads all dependencies. Everything else I can and must do manually.
-
What do you guys think for these containers? After using them for a while with VS, I think this technology is a rubbish. Too many moving parts. Versioning nightmare. URLs changing, living you high and dry, conflicts between solution and projects etc. Is it just me who is not fully appreciate/understand this library management mechanic?
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
What do you guys think for these containers? After using them for a while with VS, I think this technology is a rubbish. Too many moving parts. Versioning nightmare. URLs changing, living you high and dry, conflicts between solution and projects etc. Is it just me who is not fully appreciate/understand this library management mechanic?
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
This generations spin on DLL hell. It's not so bad when you have one or 2 packages that stand on their own. But when the packages have dependencies on other packages which depend on other packages. And one package want v2.0 and another wants v2.2, it becomes a kluge. TFS seems to choke on pulling solutions and ACTUALLY recognize package dependency. Or do recognize and tell me packages are installed but throws errors of missing references no matter how often I refresh or clean/build, etc. Often have to delete the reference and readd. Local nuget seems to have helped some.. Until a genius updates a package (or packages) and decides it should have all the latest and greatest dependent packages without thinking about downstream impact and ends up breaking stuff. Thats more of an internal problem but still an example of how wrong things can go in a nuget world. Our team has lovingly referred to it as NO-GET.
-
I've had a few run-ins with NuGet during my career, but apart from one time, nothing I couldn't fix. What really bothers me is that it tells me to update to package v5.0.0, which I know to be built on .NET 5.0, while my project is .NET Core 3.1. That's not compatible, yet it wants me to update... X| It shouldn't be that difficult to recognize my .NET version and then only show me updates for that particular version, or so you'd think.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander Rossel wrote:
It shouldn't be that difficult
Do you realize what you just wrote!!!!! Everyone who's read is is now doomed to a hell of unsolvable problems for all eternity. :doh:
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
PIEBALDconsult wrote:
Never used it.
PIEBALDconsult wrote:
Worthless.
How would you know it is worthless, if you never used it? :sigh:
-
What do you guys think for these containers? After using them for a while with VS, I think this technology is a rubbish. Too many moving parts. Versioning nightmare. URLs changing, living you high and dry, conflicts between solution and projects etc. Is it just me who is not fully appreciate/understand this library management mechanic?
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
I've got some code still running out in the wild circa 2005-ish, I used next to no external libraries, so there is not much fear of being able to fix an issue (as long as I can get the old IDE working :laugh: ) I have some newer stuff, code about 3 years old that broke badly when the vender disappeared, and the current framework broke the old vendors code. I am weary of depending on too much of external libraries like NuGet because of past experiences. Sure these libraries can speed development up like crazy if you don't care about the product 5 years down the road, or think it will all be re-written by then.
-
What do you guys think for these containers? After using them for a while with VS, I think this technology is a rubbish. Too many moving parts. Versioning nightmare. URLs changing, living you high and dry, conflicts between solution and projects etc. Is it just me who is not fully appreciate/understand this library management mechanic?
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
So I see three issues mentioned that have nothing to do with NuGet: 1. Version conflicts for common dependencies between libraries 2. Auto-updates 3. Package configurations which say a new version is compatible with your project NuGet doesn’t magically solve #1 for you, though it *can* update your references for the simple case, if you let it. Which highlights that #2 is not normally the default. Finally, #3 is the fault of the packager, not the deliverer. It’s easy to configure things wrong, and for the misconfiguration to go unnoticed if it’s new or exotic enough. What NuGet does help you solve is keeping your source control download small, especially if the bulk of your code is libraries, unless someone unknowingly checks in the “packages” folder.
-
I've got some code still running out in the wild circa 2005-ish, I used next to no external libraries, so there is not much fear of being able to fix an issue (as long as I can get the old IDE working :laugh: ) I have some newer stuff, code about 3 years old that broke badly when the vender disappeared, and the current framework broke the old vendors code. I am weary of depending on too much of external libraries like NuGet because of past experiences. Sure these libraries can speed development up like crazy if you don't care about the product 5 years down the road, or think it will all be re-written by then.
NuGet is a publishing platform. If a vendor up and disappears, your dependence on their library (maybe as an interface for their API or hardware) is still in danger whether they publish their library on NuGet, the web, or a thumb drive. At least with NuGet, you know the library is available in its present form, compared to a website the vendor stops paying for. In general, a dependency should be easily replaceable if it is intrinsic to functionality. And while larger vendors have a smaller chance of disappearing, a dependency without abstraction can still impose a risk to efficient replacement. Just ask Parler.
