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

11–20 of 49 posts

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

#11

Post by xavierdecoster »

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!

The point being made here is that although many new stuff is being shipped through NuGet, there are still way to many "implicit" dependencies to the stuff that gets shipped through SDKs, installers, vsix, etc.

Setting up a build server is a good indicator really of all these "implicit" dependencies.

File > New C# Project results in a csproj file containing references to MSBuild targets and binaries that supposedly are already installed on the system. While that's a valid assumption on a developer's machine, these dependencies are declared "implicitly". Why not make them explicit and reference the appropriate MSBuild targets and libs from .NET NuGet packages? (really whish .NET gets componentized and shipped through NuGet one day). NuGet package restore could then simply pull in all dependencies required to build the software.

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

#13

Post by maartenba »

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?

I said "most" projects :-) But even with that I don't have to go through my build logs 50 times before finding out which dependencies have to be installed for the build to work. The build should "just work".

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

#14

Post by chton »

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?

It's not perfect, but at least you don't have to manually install 10,000 files just to be able to build in the first place. Or worry that your build server is running on the wrong version of Windows. Or even do anything special to get it to build. It's not perfect, but it's better than what we have now by a huge margin.

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

#15

Post by ygra »

maartenba wrote: post #10
maartenba wrote: post #6

Earlier quoted context omitted.

That is not entirely true. For example the Windows Azure SDK has to be installed. Database tools have to be installed if you want to be able to compile a database project. There are many of the new things that do not follow this approach (hopefully: yet).

Added a P.S. to the post to reflect this: P.S.: A lot of the new packages like ASP.NET MVC and WebApi, the OData packages and such are being shipped as NuGet packages which is awesome. The ones that I am missing are those that require additional build targets that are typically shiipped in SDK's. Examples are the Windows Azure SDK, database tools and targets, ... I would like those to come aboard the NuGet train!

There's nothing technical that would prevent nuget from including MSBuild targets that are then picked up after installing the package, right? (Worst case would be that you'd have to use a wrapper project which gets the dependencies and then builds the actual project, in case project includes are handled before the nuget target.)

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

#16

Post by luser »

lucian1900 wrote: post #8
maartenba wrote: post #4

Earlier quoted context omitted.

The good CPAN times :-) It was a bit of a cumbersome thing to work with as a newbie back then but at least it handled dependencies very well.

In many ways CPAN is still state of the art. It has first-class support for namespacing and mirroring, which appears to still elude most environments' packaging systems. And I'm saying this as someone that dislikes Perl a lot.

I did some research on CPAN - comparing it to Ruby gems and Python's various packaging solutions...

CPAN is the defacto Perl standard, mirroring and testing built in. With perlbrew, localLib and cpanm, the tooling for Perl is world class. I think Ruby and Python are still catching up here. No doubt they will, but CPAN is an amazing feat of engineering.

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

#17

Post by maartenba »

ygra wrote: post #15
maartenba wrote: post #10

Earlier quoted context omitted.

Added a P.S. to the post to reflect this: P.S.: A lot of the new packages like ASP.NET MVC and WebApi, the OData packages and such are being shipped as NuGet packages which is awesome. The ones that I am missing are those that require additional build targets that are typically shiipped in SDK's. Examples are the Windows Azure SDK, database tools and targets, ... I would like those to come aboard the NuGet train!

There's nothing technical that would prevent nuget from including MSBuild targets that are then picked up after installing the package, right? (Worst case would be that you'd have to use a wrapper project which gets the dependencies and then builds the actual project, in case project includes are handled before the nuget target.)

True that! And I hope more SDK's are shipped in NuGet packages so we can define explicit dependencies instead of implicit ones.

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

#18

Post by anton_gogolev »

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 harder to update dependencies?

Fourth, dependencies. "[1.3.2,1.5)" - how cool is this?

Fifth, the whole "Package Restore" concept is flawed.

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

#19

Post by anton_gogolev »

If you have a couple minutes, take a look inside any of the Microsoft-shipped .targets file to see the mess in its full glory. That's programming in XML, kids.

It boggles my mind why Microsoft went the XML route when designing MSBuild (apparently they were copying NAnt and various other "enterprise-grade" build systems from the Java world), but it would be _so much_ better if they created a special DSL for this particular purpose.

When I see this, I want to kill a puppy or two:

   Condition="'%(Identity)' != '@(SelectedFiles)'"

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

#20

Post by jeswin »

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 have such a concept. To do stuff, you call... duh.. API!*

- The above resulted in millions of programmers not really getting it. Need a component, alright an MSI file. They don't understand how programmability of the environment can vastly simplify the act of programming itself.

- NuGet solves only a part of the problem. For non-trivial projects, there are tons of things that you need to automate besides library references.

In short, Windows is horrible if you have used anything else. And that is by design gone wrong, somewhere in the 90s.

* When they made the decision to build Powershell, they also had a chance to adopt bash or cygwin. I consider this a historic loss; the lack of a familiar/tasteful shell effectively shut (many of) the best programmers out of the Windows eco-system forever.

Post reply on HN