On the way out of the office on Friday, I stopped to talk with Justin and Nick (the other Brostein). We have all installed Visual Studio 2015 RC and have been exploring the new Task Runner Explorer. Nick had really started porting his MVC Validation Extensions library over to the Visual Studio 2015 ASP.NET 5 project structure. In the process, he had started to learn Gulp and got inspired me at the same time.

Although inspired, I was a little sad – I love automation. Automation of builds, automation of releases, automation in general; however, I haven’t yet looked at Gulp (or Grunt). I’ve built my automation stack off of MSBuild, TFS, and Release Management. Don’t get me wrong – these are great tools and accomplish the job that needs to get done. But I feel robbed – like I’ve been held back sheltered around very Microsoft-based tooling. It’s really my own fault – I could have stepped outside of my comfort zone.

A Blast from the Past?

As .NET developers, I feel we’ve been spoiled and living in an alternate reality. For years, we have lived in an MSBuild world. MSBuild, for those not familiar, is the standard tool that Visual Studio depends upon for compiling, packaging, testing, and deploying .NET solutions and projects. For MSBuild to work, you need to supply an MSBuild script, which is an XML-formatted file, describing the files to compile, and specific tasks to execute before, during, and after compilation.

Visual Studio depends upon MSBuild for two primary reasons: Visual Studio uses MSBuild as the default tool for compile and build orchestration. Being more concise, MSBuild is not the actual compiler, but instead a tool akin to a standardized “task runner” that invokes the compiler and other tools.

Visual Studio relied on MSBuild to an extend that was “beautiful” (in theory) – the project definition files (.{cs/vb/etc.}proj files) are actually MSBuild files. Further, Visual Studio managed the contents of the file automatically. As you add code to your .NET project, Visual Studio would add references to these files and dependencies so MSBuild could orchestrate the build and compile process. Some .NET developers may not even realize how much work Visual Studio did for them – without the automatic management of the .proj files, developers would have had to define (and update) the MSBuild scripts manually.

Welcome to a New World, .NET Developers

While .NET developers were living in MSBuild world, the landscape of build automation and automated task runners has grown up around us. Task running frameworks, such as Grunt and Gulp have emerged as widely used tools in the non-.NET development community.

I believe one of the key reasons .NET developers are behind in build automation (and even automation tools in general) is due to the lack of direct integration and opinionated integration of these tools in Visual Studio. This has left us in the dark. Unfortunately, we’ve been at a disadvantage and we’re now just starting to understand how far behind we are as a community. I also feel there is a “divide” between the .NET community and the rest of the development community. It’s not Microsoft’s fault, it’s not necessarily “our” fault, but I think it isn’t helpful to point finger. I’d rather talk about what we can do to bridge the gap. It’s time to catch-up, and I’m glad Visual Studio is helping us to get there through more opinionated integration with Grunt and Gulp. We’re now at a disadvantage and need to play catch-up.

ASP.NET 5 and Automation Tool Integration

You may hear that Visual Studio 2015 has ditched .proj files and MSBuild has disappeared, but this is not true. Project files still exist for MSBuild to orchestrate compilation. This rumor likely came from a confusion on the new project structure of ASP.NET 5 projects.

ASP.NET 5 has introduced a new project structure, with integration with out-of-the-box integration with task runners Grunt and Gulp. Project files also exist, but the older .proj files have been replaced with a .xproj file. The new .xproj file is not a registry of project files, but still provides configuration information for MSBuild to orchestrate the build and compile process.

Although Visual Studio 2015 and ASP.NET 5 are in RC, a wealth of information is available. I highly recommend checking out the online documentation to learn some more.