Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building .NET projects is a world of pain and here's how we should solve it

blog.maartenballiauw.be

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Building .NET projects is a world of pain and here's how we should solve it

#21

Post by chton »

anton_gogolev wrote: post #18
ndepoel wrote: post #7

NuGet gets the job done admirably, but it was simply introduced too late; nearly 10 years after the introduction of .NET. It's good to see NuGet has gained traction very quickly, but there are still plenty of projects predating NuGet that have solved the dependency management problem in their own unique way. Migrating all of those to NuGet takes time and willing maintainers.

NuGet itself leaves a lot to be desired. For one, it's used to install all kinds of crap (like jQuery) and sometimes has all too tight dependency on Visual Studio in its .ps1 scripts. Next, all the mess with having assemblies for different versions of .NET Framework inside single nupkg -- I want to see the person who decided this will be a good idea. Third, why include version numbers in directory names? To make it h…

Why would installing something like jQuery be a bad fit for Nuget? It's a dependency like any other, just because it's in JS doesn't mean you shouldn't handle it the same way you would other packages.

Versions in directory names make sense if you've got multiple projects depending on different versions of the same package. Upgrading everything at once isn't always an option.

Could you elaborate why package restore is flawed? And do you have an alternative that doesn't involve putting all your dependencies in source control?

Re: Building .NET projects is a world of pain and here's how we should solve it

#22

Post by JonoW »

chton wrote: post #9
mattmanser wrote: post #5

I'm not really sure what point you're trying to make. This seems to be exactly where MS are moving to with nuget. Like all the new stuff, the WebAPIs, EF 6, OData, etc. is now being published as NuGet packages instead of installers or SDKs or whatever. NuGet seems to be a direct response to this very issue and you constantly mention it. So what are you asking? After all they can't change the past!

Microsoft is increasingly doing it with their frameworks and components, but not for real SDKs. Windows 8 and Phone development still requires an installer to build. It's not just Microsoft though. Other vendors need to jump on the same bandwagon. Right now, almost nobody really does, definitely nobody who sells to the enterprise market.

I think they just need to separate out the tools from the libraries, within the SDKs, i.e. all libraries through NuGet, everything else can still be an Msi, as a dev will need things like emulators and VS tooling add-ins, but none of this is needed for build server just to build the project

Re: Building .NET projects is a world of pain and here's how we should solve it

#23

Post by chton »

JonoW wrote: post #22
chton wrote: post #9

Earlier quoted context omitted.

Microsoft is increasingly doing it with their frameworks and components, but not for real SDKs. Windows 8 and Phone development still requires an installer to build. It's not just Microsoft though. Other vendors need to jump on the same bandwagon. Right now, almost nobody really does, definitely nobody who sells to the enterprise market.

I think they just need to separate out the tools from the libraries, within the SDKs, i.e. all libraries through NuGet, everything else can still be an Msi, as a dev will need things like emulators and VS tooling add-ins, but none of this is needed for build server just to build the project

I whole-heartedly agree. It does create some danger there of mismatching versions between the tooling and the nuget packages. What do we do if the user has upgraded to a newer version of the package, but hasn't updated his emulator yet? Vice versa is somewhat easier to enforce, but either way it will require careful checking and notifying of the devs.

Re: Building .NET projects is a world of pain and here's how we should solve it

#24

Post by anton_gogolev »

chton wrote: post #21
anton_gogolev wrote: post #18

Earlier quoted context omitted.

NuGet itself leaves a lot to be desired. For one, it's used to install all kinds of crap (like jQuery) and sometimes has all too tight dependency on Visual Studio in its .ps1 scripts. Next, all the mess with having assemblies for different versions of .NET Framework inside single nupkg -- I want to see the person who decided this will be a good idea. Third, why include version numbers in directory names? To make it h…

Why would installing something like jQuery be a bad fit for Nuget? It's a dependency like any other, just because it's in JS doesn't mean you shouldn't handle it the same way you would other packages. Versions in directory names make sense if you've got multiple projects depending on different versions of the same package. Upgrading everything at once isn't always an option. Could you elaborate why package restore is…

Because there's a ton of package managers for JavaScript and NuGet is reinventing the wheel here, squared. Granted, very few (if any) of them work on Windows, but that's outside the scope here.

And even if we accept that it's OK for NuGet to install JS dependencies, where do we draw the line? Install Bootstrap with NuGet? FontAwesome? Should NuGet execute SQL scripts while installing Elmah? Install MSI packages as part of "install-package"?

All in all, DLLs are the most dominant type of dependencies for .NET and NuGet should laser-focus on those.

As for multiple projects within the same solution depending on different versions of packages, that's asking for trouble. And again, why default to the illogical behavior of including version numbers in directory names when this is only justified in like 0.1% of cases?

Package Restore is _very_ fragile, both in terms "what happens if NuGet server is down" and in terms of "Visual Studio has gone mad and does weird shit trying to restore packages".

And I saw you using "source control" implying that the only thing to belong there are text-only source files. What if we call it "version control"? This will magically allow us to put all the binary dependencies and live a happy life. Cheers!

Re: Building .NET projects is a world of pain and here's how we should solve it

#25

Post by chton »

anton_gogolev wrote: post #24
chton wrote: post #21

Earlier quoted context omitted.

Why would installing something like jQuery be a bad fit for Nuget? It's a dependency like any other, just because it's in JS doesn't mean you shouldn't handle it the same way you would other packages. Versions in directory names make sense if you've got multiple projects depending on different versions of the same package. Upgrading everything at once isn't always an option. Could you elaborate why package restore is…

Because there's a ton of package managers for JavaScript and NuGet is reinventing the wheel here, squared. Granted, very few (if any) of them work on Windows, but that's outside the scope here. And even if we accept that it's OK for NuGet to install JS dependencies, where do we draw the line? Install Bootstrap with NuGet? FontAwesome? Should NuGet execute SQL scripts while installing Elmah? Install MSI packages as pa…

There's a ton of package managers, but none that are as built into the platform as nuget is. On top of that, what advantage would there be in having multiple package managers? All you're doing is making the package management harder by splitting it up. How would I indicate my Nuget package depends on a specific version of jQuery?

The line is simple to draw: Nuget should never install anything. It's not chocolatey or aptitude. It provides versioned files, no more. That is its focus, and should remain it, no matter what those files contain.

DLLs are dominant, but definitely not the only type of dependency. Dependencies on text files, javascript, or just about anything else need to be versionable using the same system. If not, you would run into the issues mentioned above.

Multiple projects with different version dependencies might usually be a bad idea, but it's still something you need to support. Unlike some other systems, Nuget can't be opinionated about how you manage your projects. If it was, it would be dropped like a rock by enterprises that don't want to adapt to the package manager of choice. If that makes it harder to do something the platform does for you, nobody really loses.

Package restore is more fragile than local assemblies, yes. We've seen that a few times lately when Nuget was down. These are risks that can be mitigated though, by providing mirrors and a decent local cache.

Putting any sort of binary dependency in a version control system is a problem. They can't be compared to previous versions. Unless you make folders for each version of the package you depend on, you also can't depend on different versions in your projects. And worst of all, if a dev decides to replace a package, it could break something else. Those (and others) are exactly the reasons package managers were created in the first place.

Re: Building .NET projects is a world of pain and here's how we should solve it

#26

Post by LoneWolf »

Instead of node I would say look at Maven, I never had a problem with a java project that used maven, all I ever needed was maven, and a JDK.

It may not be the best out there but to me seems pretty good considering it is as simple as download source code, and run "mvn package".

Re: Building .NET projects is a world of pain and here's how we should solve it

#27

Post by thespace123 »

MichaelGG wrote: post #12

>Let’s look at the Node.js community and how they manage to do things Node.js? The one that pulls in like 10,000 files to run a simple grunt build?

The benefit of npm is that everything is modular and patchable. To me it outweighs the 10,000 files issue.

Re: Building .NET projects is a world of pain and here's how we should solve it

#28

Post by wesnerm2 »

jeswin wrote: post #20

Building .Net projects cannot really be solved in a way that compares well with nix systems. - Windows had no programmability until recently with Powershell. On Linux, I can script literally everything from database installs to component updates. - Powershell. Unfortunately they got their design wrong. Unix is a text and file based OS; you can script any server configuration with tools like awk. Windows apps doesn't…

Even before PowerShell, Windows had thousands of COM objects in the system that can invoked within a scripting language like .vbs or any language that has APIs for accessing com objects like ActiveState perl. The Windows Explorer shell, Windows Media Player, not to mention Microsoft Office applications, have object models that are exposed and available to programmed against. I am not so sure that UNIX has anything better, since it seems all the functionality that UNIX has is also available in Windows. Then, there is also WMI (Windows Management Instrumentation) objects for all the low-level system operations.

Re: Building .NET projects is a world of pain and here's how we should solve it

#29

Post by cincinnatus »

It's just a different bag of hurt but no more so than node or ruby. Setting up ruby boxes makes me homicidal, whereas .net feels like nothing. But then I have much more experience with the latter, and 'evolved' with it and it's precursors.

That said, building .net is relatively trivial and it's tools are caught up.

I think what he's looking for is http://fsharp.github.io/FAKE/

Re: Building .NET projects is a world of pain and here's how we should solve it

#30

Post by romanovcode »

jeswin wrote: post #20

Building .Net projects cannot really be solved in a way that compares well with nix systems. - Windows had no programmability until recently with Powershell. On Linux, I can script literally everything from database installs to component updates. - Powershell. Unfortunately they got their design wrong. Unix is a text and file based OS; you can script any server configuration with tools like awk. Windows apps doesn't…

So where is the problem? Installing stuff? Yeah, it's not as easy, as for example `sudo apt-get install make autoconf automake libgif-dev libtool g++ gettext libglib2.0-dev libpng12-dev libfontconfig1-dev mono-gmcs git libx11-dev libexif-dev libjpeg-dev libpng-dev libtiff-dev`.

But it doesn't change the fact that everything needs gazillion of other dependencies. I have no problem installing MSI files on production server and then leave it be for couple of years.

Post reply on HN