Building .Net projects cannot really be solved in a way that compares well with nix systems.<p>- Windows had no programmability until recently with Powershell. On Linux, I can script literally everything from database installs to component updates.<p>- 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!*<p>- 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.<p>- 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.<p>In short, Windows is horrible if you have used anything else. And that is by design gone wrong, somewhere in the 90s.<p>* 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.
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.<p>That said, building .net is relatively trivial and it's tools are caught up.<p>I think what he's looking for is
<a href="http://fsharp.github.io/FAKE/" rel="nofollow">http://fsharp.github.io/FAKE/</a>
>Let’s look at the Node.js community and how they manage to do things<p>Node.js? The one that pulls in like 10,000 files to run a simple grunt build?
This is something Microsoft needs to push instead of the insane MSI stuff. Microsoft really needs an officially sanctioned dependency manager, maybe NuGet. Something with a standardized package format based on _archives_, not _executable installers_.<p>The Microsoft ecosystem is light years behind OSS in this regard. Heck, CPAN was designed in 1993 and became available in 1997. Truly light years - CPAN predates the dot-com boom.
NuGet gets the job done admirably, but it was simply introduced too late; nearly 10 years after the introduction of .NET.<p>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.
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.<p>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".
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.<p>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.<p>When I see this, I want to kill a puppy or two:<p><pre><code> Condition="'%(Identity)' != '@(SelectedFiles)'"</code></pre>
Not that I'm really against this article, but psake (<a href="https://github.com/psake/psake" rel="nofollow">https://github.com/psake/psake</a>) is a more realistic end-goal to handle the kind of flexibility you really need in projects. (It's accomplishable through MSBuild pre/post actions, but those are murder to edit anywhere but Visual Studio.) The problem with it, which is potentially a big one, is that psake uses PowerShell, and is therefore Windows-only. I'm hopeful that PowerShell can be ported to Unix soon as part of the general open-sourcing of Microsoft's .NET stack. I wouldn't use PowerShell as a replacement for bash, but as a cross-platform equivalent to Groovy/CRaSH, it'd be very handy for exactly this kind of thing. (Think of how Gradle fits into the Java world.)
The biggest offender for me, besides nuget being pretty much useless for real work, is that you need to install Visual Studio to automate <i>headless</i> ASP.NET builds! That's insane. Even the simplest most barebones ASP project requires it. As a result, our Chef scripts include downloading and installing a bunch of MSIs from S3. I would love to be proven wrong.
> Let’s look at the Node.js community and how they manage to do things.<p>I think NuGet is much better then npm. When you download something from NuGet you get a dll file that is injected in your References. When you download something with npm --save-dev you get 1000+ files.<p>Just sayin'
I'm not really sure what point you're trying to make. This seems to be exactly where MS are moving to with nuget.<p>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.<p>NuGet seems to be a direct response to this very issue and you constantly mention it.<p>So what are you asking? After all they can't change the past!