Many Users Still Not Drinking The NuGet Kool-Aid

by Jon Davis 22. July 2015 02:40

Yesterday (I say “yesterday” as if it was a day ago, but it’s 1:50 AM and I need some sleep) three employees of my client’s and I spent an hour, plus just themselves another hour prior, trying to fuss and fiddle to get TFS 2012 solution to build a project. The problem: we were choosing not to include the NuGet packages binaries into TFS, but NuGet packages were not properly getting restored.

The team I’m currently supporting manages literally tens (more than 100, actually) different deployed I.T. solutions, some of them old, some of them new, most of them rather small, and all of them needing to be maintained on a regular basis simply because “technology”. Only a very small handful of these solutions actually use NuGet, thank heavens. The rest of the apps just go the old fashioned method of having a “lib” directory (actually a “References” folder or “ProjectReferences” folder but whatever, other companies I’ve been in call it “lib”). I’ve been with or consulted with at least 15 to 20 different companies or more over my career, and among those who knew about NuGet (about four or five or so) the majority of my experiences have seen the teams treat NuGet like a virus. And with good reason, too. Multiple projects means multiple different iterations of fetching “whatever flavor of Package X is out there”. Multiple employees means multiple different package choices. Throw it all together and you end up with a mess of four or five different versions of client-side and server-side NuGet packages all from different times by different people, and at the end of it all it’s so often a hackfest to get Visual Studio and whatever CI build server to cooperate with the whole package restore process at all.

And package restore has another fundamental flaw by design: being what it is, it actually expects the build to download dependencies in order to build. The TFS build server doesn’t have Internet access. The team will never give the TFS build server Internet access, not to fetch NuGet packages, not for any other reason. The team controls dependencies, as many enterprises should. So NuGet packages are copied out to a corporate Windows file share on the WAN. On the local developer workstations, Visual Studio is set up to only apply NuGet packages from this share. But TFS isn’t Visual Studio.

But that wasn’t even the only issue. In our case yesterday whoever worked on this solution forgot to right-click on the solution in Solution Explorer and click on the magical menu option, “Enable package restore for this solution”. Oh, we had been through this before. Hours and hours of repeat fiddling in projects past had led to team documentation about the proper process .. and, ironically, the magical menu option wasn’t even documented. Rather, “find the .nuget folder from another working NuGet-based application and bring them over into your solution’s solution folder, then manually edit the solution and project.” Great. So now we’re literally opening up the .csproj—XML gobbligook I’ve only recently become comfortable with because of what led to Fast Koala, but up to that point .csproj files were black magic to me—and throwing in custom <Target> tags and <PropertyGroup> properties and <ItemGroup> items, .. oh my! But in our case yesterday, since we did use the magical menu item, we initially tried to deploy with (mostly) defaults in the generated .nuget folder, but because of our unique solution/project team convention folder structure we had to move the packages folder around. (We also had to manually declare our Windows file share for NuGet package sources. But we had documented this.) This meant we had corrupt NuGet package references in the projects that already referenced the NuGet packages from before we set up package restore for the solution. So we reinstalled the NuGet packages. And we discovered that the binaries were then somehow not referenced. So we manually added the binary references, pointing to the packages folder. It still didn’t work on TFS. So we uninstalled the NuGet packages. And then we reinstalled the NuGet packages. And we fiddled with missing configuration details in the .csproj file. And behold, the TFS build spat out a green checkbox.

And after all that, the four of us were blinking at our machines (we were all gathered together using Lync [aka Skype for Business *rolling eyes*]) wondering, “What .. the actual .... uh what just happened? How did we get here? What is the answer to this NuGet mess?” And we all agreed: “There is no answer. NuGet is a nightmare, and you have to keep poking at it and fussing with it for an hour or two to get it to cooperate, if you didn’t do it right or know how to do it right to begin with.”

This was supposed to be a time-saver. It was supposed to make our lives easier than manually grabbing files off the third party web sites that provided them. Well I’m sorry, but after cataloguing our dependencies I think what took us two hours to troubleshoot a thing would have taken five minutes managing a lib directory, max. Sure, that’s about four minutes longer than working with the NuGet console, if every team member is consistent in how he uses NuGet. Get real!

Here’s the core issue I have with NuGet: it’s still third party. Microsoft has adopted and embraced NuGet, but MSBuild has absolutely no clue, zero, zilch, nada, no comprehension what the heck a NuGet package is. Everything is manually scripted, manually spoonfed, and these conventions with the .nuget folder and dropping a NuGet.exe in there and all this noisy config/setup crap is all workaround boilerplating that is dreadfully needing and pleading Microsoft to bake into Visual Studio, MSBuild, and TFS properly.

We had the same problem with MSDeploy. Who uses that, really? (I ask this in the same mind of, “Who uses Azure anyway?” Surely plenty but there are still many of us who don’t, yet we are still Microsoft stack developers.) MSDeploy and ClickOnce publishing is so painfully externalized black box and GUI-minded that for those of us actually trying to automate getting work done it’s easier to just write scripts. Really. In most cases it seems to be mandatory.

So Microsoft’s answer to the problem was to make the problem worse, by introducing native support for ‘bower’. Well, that’s not fair. They made the problem .. ehh .. more complicated. At least with ASP.NET 5 they no longer push client-side libs through NuGet. That fixes shifts that part of the problem to another equivalent yet completely different technology, one not maintained by the .NET community, but then again, it doesn’t need to since front-end web technology is vendor-neutral by necessity. But now we have to support ‘bower’, on top of NuGet. And what is the TFS story on this?! Oh that’s right, there is no Build process with ASP.NET 5, not really. We’re back to ASP.NET 1.1 web sites with mandatory dynamic generated code compilation. No more .csproj project manifests. Whatever’s in the file system is part of the project. The only difference here, other than gulp and bower via Node.js integration into ASP.NET where it feels like it doesn’t belong (sex with a strange cousin seven freaky generations removed?), is the new Roslyn compiler that makes performant compile-at-any-time behavior more, .. ehh, modern. But without a project manifest you now have very limited control of your project files and their behaviors. Welcome back ASP.NET 1.1 websites, we missed you. (Not.)

I’m sidetracked. This wasn’t supposed to be about ASP.NET 5, it was supposed to be about NuGet. I don’t know what the answer should be about NuGet, other than I think that if Microsoft is going to keep building upon NuGet for the development stack they need to get the convention-over-configuration notion working properly, because NuGet support here on ASP.NET MVC 5 projects with TFS CI build automation is a living configuration hell if not done carefully, sequentially.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Announcing Fast Koala, an alternative to Slow Cheetah

by Jon Davis 17. July 2015 19:47

So this is a quick FYI for teh blogrollz that I have recently been working on a little Visual Studio extension that will do for web apps what Slow Cheetah refused to do. It enables build-time transformations for both web apps and for Windows apps and classlibs. 

Here's the extension:  

Here's the Github:

Either link will explain more.


Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 

Tag cloud


<<  May 2021  >>

View posts in large calendar