I've Gone off NuGet enormously
-
At first NuGet seemed a good idea - the kind of package management Node and Rust have taken for granted for ages. Recently though, I'm keep getting stuffed by conflicts, bugs and wierdities. Many of my projects reference Newtonsoft Json.Net 10.0.3. Somehow NuGet resolves this with version 6.0.x. FFS - thats 4 major versions out-of-date. Been using OWIN packages, and getting similar issues. Still haven't got to the bottom of this one. The whole thing is beginning to remind me of DLL Hell and ActiveX components under VB6. WTF happened? I thought .NET was designed to get us away from this excrement. (Love the fact the editor here includes , but not the matching end tag)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Never used it.
-
Rob Grainger wrote:
Recently though, I'm keep getting stuffed by conflicts, bugs and wierdities.
Recently? I've never had NuGet behave properly. And that BS about changing something in some config file to override the version number, well, it's just that, BS. My SOP: 1. If I can, I compile the source directly and add to my project the necessary DLL's. This is often fraught with problems, as people can't seem to provide source code that actually compiles, or doesn't compile with the .NET framework that I'm using, or doesn't provide a SLN file, or has all sorts of project kruft that I don't need or care about. 2. Failing #1 (happens often enough) I create a separate project, do the PM NuGet BS, grab the DLL's from the appropriate .NET version folders, put them in a "Libs" folder that my real project then references, and delete the temporary project. And the very elephanting last thing I need/want is for some package to update itself, breaking code, breaking other dependencies, etc. Marc
Latest Article - Create a Dockerized Python Fiddle Web App Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
I do exactly the same - I have a project called NuGet - I don't bother deleting it. The last thing I need is to open an old project and have that $#%@^&*ing thing wander of and update packages. It never really worked smoothly for us, this may have been caused by the corporate centurion dissalowing the connection in the early days.
Never underestimate the power of human stupidity RAH
-
The only thing worse than NuGet is when people don't realise you don't need a NuGet package to use JSON ;P
Thing is, it is used by default in some of Microsoft's own project templates and packages. Sometimes you don't have much choice.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Rob Grainger wrote:
Recently though, I'm keep getting stuffed by conflicts, bugs and wierdities.
Recently? I've never had NuGet behave properly. And that BS about changing something in some config file to override the version number, well, it's just that, BS. My SOP: 1. If I can, I compile the source directly and add to my project the necessary DLL's. This is often fraught with problems, as people can't seem to provide source code that actually compiles, or doesn't compile with the .NET framework that I'm using, or doesn't provide a SLN file, or has all sorts of project kruft that I don't need or care about. 2. Failing #1 (happens often enough) I create a separate project, do the PM NuGet BS, grab the DLL's from the appropriate .NET version folders, put them in a "Libs" folder that my real project then references, and delete the temporary project. And the very elephanting last thing I need/want is for some package to update itself, breaking code, breaking other dependencies, etc. Marc
Latest Article - Create a Dockerized Python Fiddle Web App Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Thanks for the ideas - that may help. Have to agree on Point 1 too - that and Blog posts with source code the author can never have got working. Think I have a CP article coming from my recent experiences though - getting good Integration testing working on the MVC stack.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Are you adding it directly, or as a dependency of another package? It could be the "Dependency behavior" setting: NuGet Package Manager UI Reference | Microsoft Docs[^] NuGet Package Dependency Resolution | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
I've had problems in both cases. Thanks for the links though.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
At first NuGet seemed a good idea - the kind of package management Node and Rust have taken for granted for ages. Recently though, I'm keep getting stuffed by conflicts, bugs and wierdities. Many of my projects reference Newtonsoft Json.Net 10.0.3. Somehow NuGet resolves this with version 6.0.x. FFS - thats 4 major versions out-of-date. Been using OWIN packages, and getting similar issues. Still haven't got to the bottom of this one. The whole thing is beginning to remind me of DLL Hell and ActiveX components under VB6. WTF happened? I thought .NET was designed to get us away from this excrement. (Love the fact the editor here includes , but not the matching end tag)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Another thing you might want to consider is taking the specific packages you want your project(s) to use, and building your own custom NuGet feed with them. Granted, it's a bit of a hassle, but at least you'll have full control of the packages.
-
At first NuGet seemed a good idea - the kind of package management Node and Rust have taken for granted for ages. Recently though, I'm keep getting stuffed by conflicts, bugs and wierdities. Many of my projects reference Newtonsoft Json.Net 10.0.3. Somehow NuGet resolves this with version 6.0.x. FFS - thats 4 major versions out-of-date. Been using OWIN packages, and getting similar issues. Still haven't got to the bottom of this one. The whole thing is beginning to remind me of DLL Hell and ActiveX components under VB6. WTF happened? I thought .NET was designed to get us away from this excrement. (Love the fact the editor here includes , but not the matching end tag)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
I have never used NuGet as I install all my necessary tools manually. I have never had a problem doing it this way so why use an automated system that can cause you problems?
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
At first NuGet seemed a good idea - the kind of package management Node and Rust have taken for granted for ages. Recently though, I'm keep getting stuffed by conflicts, bugs and wierdities. Many of my projects reference Newtonsoft Json.Net 10.0.3. Somehow NuGet resolves this with version 6.0.x. FFS - thats 4 major versions out-of-date. Been using OWIN packages, and getting similar issues. Still haven't got to the bottom of this one. The whole thing is beginning to remind me of DLL Hell and ActiveX components under VB6. WTF happened? I thought .NET was designed to get us away from this excrement. (Love the fact the editor here includes , but not the matching end tag)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
[Paket](https://fsprojects.github.io/Paket/faq.html) may be of interest - uses Nuget infrastructure, but manages transitive dependencies as well...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
At first NuGet seemed a good idea - the kind of package management Node and Rust have taken for granted for ages. Recently though, I'm keep getting stuffed by conflicts, bugs and wierdities. Many of my projects reference Newtonsoft Json.Net 10.0.3. Somehow NuGet resolves this with version 6.0.x. FFS - thats 4 major versions out-of-date. Been using OWIN packages, and getting similar issues. Still haven't got to the bottom of this one. The whole thing is beginning to remind me of DLL Hell and ActiveX components under VB6. WTF happened? I thought .NET was designed to get us away from this excrement. (Love the fact the editor here includes , but not the matching end tag)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Thinking back to how MicroSoft would build the O/S and take the COMPUTER and save it in a vault, in case they had to go back and change anything.... Because... Well... Managing changing environments, and recompiling to get the same result was NEXT TO IMPOSSIBLE... Now, we have IDEs (and plugins) that depend on the same code that they are likely to use, such that changing one of the DLLs you are working with runs the risk of breaking either the IDE or the code you need. Then generating a Cross Product (times multiple packages) to increase that risk. So... The answer is a tool to make adding more packages EASIER... Suddenly: Doing the same thing, over and over, and expecting a different result comes to mind...
-
At first NuGet seemed a good idea - the kind of package management Node and Rust have taken for granted for ages. Recently though, I'm keep getting stuffed by conflicts, bugs and wierdities. Many of my projects reference Newtonsoft Json.Net 10.0.3. Somehow NuGet resolves this with version 6.0.x. FFS - thats 4 major versions out-of-date. Been using OWIN packages, and getting similar issues. Still haven't got to the bottom of this one. The whole thing is beginning to remind me of DLL Hell and ActiveX components under VB6. WTF happened? I thought .NET was designed to get us away from this excrement. (Love the fact the editor here includes , but not the matching end tag)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
I (and the company I work for) was late to package management, and even now we avoid it where possible, but some Nuget packages have crept in out of necessity. When I first started with it about 2-3 years ago, it worked flawlessly every time for me (though admittedly our usage was light). Unfortunately it seems to have been broken and then gotten worse with every iteration released since then. I really don't know why. I had a problem the other day where a project showed a broken reference, but Nuget insisted the package was installed ok. Checking the csproj file showed it was referencing version 9.x.x.x of a package, but the packages folder contained only 8.x.x.x. No amount of cajoling would convince Nuget that it needed to download the new version even though VS knew the reference was broken. Only thing that worked was forcing a reinstall of the package. Having said that not all problems are caused by Nuget itself. Strong named packages are evil - we have some solutions that have a mix of .Net 4 and .Net 4.5 projects in them that all reference the same package (don't ask). All the assemblies ship and run together and it all works fine until you get strong named package and you can't reference the newer version from the .Net 4 projects. Then you're in a world of pain trying to manage the dependencies. On top of that, at least one of the Microsoft provided Azure packages decided it would be a good idea to rename an entire namespace (or move types to another namespace at the very least), so upgrading from version X to version Y is breaking at the source level with no explanation or release note to say so. When it works I prefer it to downloading and running installers, then having to manually locate the right assemblies (are they in the gac? in a folder? which folder? somewhere under program files or program files x86? what was the company name again?) etc. Especially nice when you don't have to do this on build servers. Sadly the experience is so broken we do everything we can to avoid it now. Really the only thing I want from Nuget is for the package restore to work properly, i.e I add a package to a project and check in, my colleague gets latest and builds, and the package is downloaded and referenced correctly on their PC. We've had zero success with this in the last year or so. It's always broken and people are always checking in csproj changes just to fix references/broken reference paths. I really don't get why since it used to work. Haven't tried Paket - sort of appealing, but I'm led to bel
-
The only thing worse than NuGet is when people don't realise you don't need a NuGet package to use JSON ;P
F-ES Sitecore wrote:
you don't need a NuGet package to use JSON ;-P
I've only just recently started using Newtonsoft for JSON. I assumed there was probably another way to get it besides NuGet, but I haven't had the time to research alternatives. Can you take a moment to describe your workflow in this regard?
-
F-ES Sitecore wrote:
you don't need a NuGet package to use JSON ;-P
I've only just recently started using Newtonsoft for JSON. I assumed there was probably another way to get it besides NuGet, but I haven't had the time to research alternatives. Can you take a moment to describe your workflow in this regard?
You can use things like DataContractJsonSerializer to work with JSON, there are other built-in classes too depending on what version of .net you're using.
-
Rob Grainger wrote:
Recently though, I'm keep getting stuffed by conflicts, bugs and wierdities.
Recently? I've never had NuGet behave properly. And that BS about changing something in some config file to override the version number, well, it's just that, BS. My SOP: 1. If I can, I compile the source directly and add to my project the necessary DLL's. This is often fraught with problems, as people can't seem to provide source code that actually compiles, or doesn't compile with the .NET framework that I'm using, or doesn't provide a SLN file, or has all sorts of project kruft that I don't need or care about. 2. Failing #1 (happens often enough) I create a separate project, do the PM NuGet BS, grab the DLL's from the appropriate .NET version folders, put them in a "Libs" folder that my real project then references, and delete the temporary project. And the very elephanting last thing I need/want is for some package to update itself, breaking code, breaking other dependencies, etc. Marc
Latest Article - Create a Dockerized Python Fiddle Web App Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
One problem with NuGet is Visual Studio itself. It assumes you will organize everything at the solution level, so if you're working with a code base with multiple solutions, there are package folders littered everywhere! Then there are out and out bugs in MSVS. Try centralizing your downloaded packages into one package folder and it all starts going south... Anyway I've done pretty much what Marc describes above. I create a ThirdParty solution that I use to download all NuGet packages I want to use. They all get downloaded into the ThirdParty solution's package folder, where literally everything in the package folder gets put into source control. This pattern allows me to download and keep multiple versions of the same NuGet package so that legacy applications are able to use an older version if, for some reason, it is withdrawn. From there, any other solutions that want to use a NuGet package will simply use a file reference for the dll directly from the ThirdParty package folder. Source code from other vendors are included as projects to the ThirdParty solution and again those libraries can be referenced from a solution as a file reference.
