Introducing Gulp, Grunt, Bower, and npm support for Visual Studio
Sponsored By
Web Development, specifically front end web development, is fast becoming as complex and sophisticated as traditional back end development. Most projects don't just upload some JS and CSS files via FTP. There's now a front end build process that can include expansion of SASS and LESS, minification of CSS/JS, running JSHint or JSLint, and much more. These build tasks and processes are coordinated with tools like Gulp and Grunt. Additionally, client-side libraries are managed as packages using management systems like npm and bower.
Why client-side package managers for ASP.NET? Why not NuGet? Why not MSBuild?
Some of you may ask, why not use NuGet for JavaScript? Why not extend MSBuild for building CSS/JS? Simple. Because there's already a rich ecosystem for this kind of thing. NuGet is great for server side libraries (and some client-side) but there are so many more CSS and JS libs on npm and bower. MSBuild is great for server-side builds but can be overkill when building a client-side app.
So, use both. These are tools in your toolkit. Adding support for Gulp, Grunt, Bower, npm (and other stuff, in the future if needed) means a more familiar environment for front-end devs doing ASP.NET and it opens the doors for ASP.NET devs to bring in the JS and CSS libraries communities use every day.
Introducing Task Runner Explorer
We’ve received a ton of feature requests regarding Grunt/Gulp support from many of you as well as the community at large. We are building first-class support for both Grunt and Gulp in Visual Studio “14” with full extensibility. Now we’re ready to ship a preview of this support as an extension to VS2013 and would appreciate your help testing and exploring this feature.
Today we're introducing a preview of the "Task Runner Explorer" as a VSIX extension. We're also recommending two other VSIXs to round out the experience for this feature.
NOTE: Much of the functionality included in these multiple VSIX extensions will be built into Visual Studio so you won't need to install so many things. However, for VS2013 and this preview we needed multiple VSIXs in order to get you the bits sooner than later. Also note that today only Task Runner Explorer will work on Visual Studio Express but for VS14 all the features will work in the free VS Express version.
Consider these features as a "DevLabs" preview for now, much like the VS Productivity Power Tools. They'll graduate into the final product.
What do you need?
First, you'll need Visual Studio 2013.3 - that 3 means "Update 3" which is a free update.
- TRX - Task Runner Explorer Visual Studio Extension
- NPM/NBower Package Intellisense - Search for online NPM and Bower packages directly with Intellisense
- Optional Grunt Launcher (gives right-click options in Solution Explorer - including "npm install")
- Without this extension, for now you'll need to run npm install yourself to restore/add packages.
- If you DO have this extension, right click on packages.json and "npm install" before running a grunt/gulp task.
To open the TRX (Task Runner Explorer), simply right-click any gruntfile.js in your project:
The TRX sits at the bottom of VS by default and looks like this:
Here we can see that it found a gruntfile.js in the root of one or more projects in the solution. It also shows the task bindings feature that allows any task or target to be triggered by 4 different Visual Studio events.
To associate a task/target with a VS event, just right-click and setup bindings.
To run any task/target, just double-click it and a console appears:
When you've got the Package Intellisense Extension you'll find it easy to add and update packages when directly editing your package.json for both bower and npm.
You'll even get metadata tooltips populated asynchronously.
As you go testing it, remember you'll need to run "npm install" before you use the Task Runner Explorer to run Grunt tasks.
Big thanks to Mads Kristensen, Dan Chartier, and Van Kichline for their great work on this feature!
Sponsor: Many thanks to Intersoft for sponsoring the feed this week! Enterprise cross-platform native apps development made painless with Intersoft Crosslight. Sounds too good to be true? See it for yourself and get started today!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
September 02, 2014 22:58
Nice. Now maybe I can use one IDE, rather than one frontend and one backend.
Dan Kline
Scott, could you please send my congratz to the team about this specific feature? You guys are moving so fast and in the right direction. We regular devs really appreciate this.
Thank you so much for this feature!
Quick question: where should we log bugs and/or feedback?
Quick question: where should we log bugs and/or feedback?
Scott, it would be helpful if you could elaborate on Grunt and Gulp, how they work together, when they actually run, and who the target audience is for this. From quickly browsing the websites for both projects, they seem like they're for devs on a Node.js stack. As an ASP.NET developer, it's not clear to me how this could fit in or be beneficial.
Thanks!
Thanks!
This Task Runner Explorer seems like a good step in the right direction.
@Sam: It's briefly mentioned in the opening to this article, but gulp and grunt are two alternative (you pick one or the other, for the most part) JS build engines (that run on Node.JS). In the ASP.NET world you tend to interact with them for front-end build processes where JS (or CoffeeScript or TypeScript) is the "native" language of the tool you need for a build step. Most of the best minifiers and optimizers for JS (uglify/CoffeeScript/TypeScript) and CSS (LESS/SASS), for two examples, are being written in JS at this point and gulp/grunt automates them into a pipeline (make/msbuild for JS essentially). The most common reason I use a gulp/grunt build in ASP.NET applications is for "r.js optimization", which bundles and minifies AMD (asynchronous module definition) modules (which are themselves built in TypeScript). I've seen partial C# reimplementations of r.js, but none of them have the power of r.js and r.js is written in the same language being bundled/minimized/optimized and owned by the same team that owns the require.js loader that it optimizes for and so it tends to get a lot more eyeballs and updates/fixes/features faster.
@Sam: It's briefly mentioned in the opening to this article, but gulp and grunt are two alternative (you pick one or the other, for the most part) JS build engines (that run on Node.JS). In the ASP.NET world you tend to interact with them for front-end build processes where JS (or CoffeeScript or TypeScript) is the "native" language of the tool you need for a build step. Most of the best minifiers and optimizers for JS (uglify/CoffeeScript/TypeScript) and CSS (LESS/SASS), for two examples, are being written in JS at this point and gulp/grunt automates them into a pipeline (make/msbuild for JS essentially). The most common reason I use a gulp/grunt build in ASP.NET applications is for "r.js optimization", which bundles and minifies AMD (asynchronous module definition) modules (which are themselves built in TypeScript). I've seen partial C# reimplementations of r.js, but none of them have the power of r.js and r.js is written in the same language being bundled/minimized/optimized and owned by the same team that owns the require.js loader that it optimizes for and so it tends to get a lot more eyeballs and updates/fixes/features faster.
Sam,
Both Grunt and Gulp are task libraries similar to say MSBuild or PSake and are very common tools for managing the packaging of client side scripts. Both Bower and NPM are package managers similar to NuGet. There seems to be a movement to split client side and server side javascript into two package managers ATM, with bower being client side, NPM being both.
As for the benifit, think of it as bringing the mountain to Mohamed. Modern client side development is done using bower, npm, gulp and grunt. Current ASP.NET practices are a bit behind the times. If your team were to go out and hire an experienced front end web developer, they would expect to see these tools being used.
ASP.NET has been a bit of a walled garden for almost a decade. If you want to hire the best, support the tooling they want to work with is a good idea. It's really awesome to see this stuff moving into the realm of possibility in .NET. I am actually excited to do .NET development again.
Both Grunt and Gulp are task libraries similar to say MSBuild or PSake and are very common tools for managing the packaging of client side scripts. Both Bower and NPM are package managers similar to NuGet. There seems to be a movement to split client side and server side javascript into two package managers ATM, with bower being client side, NPM being both.
As for the benifit, think of it as bringing the mountain to Mohamed. Modern client side development is done using bower, npm, gulp and grunt. Current ASP.NET practices are a bit behind the times. If your team were to go out and hire an experienced front end web developer, they would expect to see these tools being used.
ASP.NET has been a bit of a walled garden for almost a decade. If you want to hire the best, support the tooling they want to work with is a good idea. It's really awesome to see this stuff moving into the realm of possibility in .NET. I am actually excited to do .NET development again.
Really great improvement. I recently started using Bower for all frontend related JSish libraries instead of Nuget, and wrote why in this blog post tinyurl.com/ThePowerOfBower
Really looking forward to try out some of the new web features
Really looking forward to try out some of the new web features
Great stuff :) Can you elaborate on how this new support works with say an asp.net site where the cs code is built with msbuild? How does the gulp/grunt stuff work in those cases?
Also, how about in a CI scenario? Would one build with msbuild first and then with gulp/grunt? The other way around? It would be really nice if msbuilt could bootstrap the front end builds and perhaps have tooling support similar to nuget where VS could also set up the tools for CI builds
I imagine most folk using this feature will be coming from the asp.net side and perhaps be less experienced in using the other tools :)
Also, how about in a CI scenario? Would one build with msbuild first and then with gulp/grunt? The other way around? It would be really nice if msbuilt could bootstrap the front end builds and perhaps have tooling support similar to nuget where VS could also set up the tools for CI builds
I imagine most folk using this feature will be coming from the asp.net side and perhaps be less experienced in using the other tools :)
This is the best news I've read about .NET in a long time. Can't wait to try it.
Hot damn! This is a most welcome addition. Totally agree with Dan Kline's single IDE comment. VS 2014 going to be a very formidable front & back end tool.
I've heard rumors of such integration, so I can't wait to get update 3 installed and kick the tires on these! Even though most of my development is now in JavaScript, Visual Studio is still my IDE of choice.
Our teams have completely switched over to Bower from NuGet for client-side packages for several months now. We're using Gulp as our build tool for Angular apps with a MVC and Web API backend. After some blood, sweat and tears we were able to bypass our reliance on System.Web.Optimization for bundling, which had given us all sorts of pain.
I wrote quite the essay on our experiences in the form of a comparison of Bower vs. NuGet that your team may also find helpful: Why Bower is better than NuGet.
Kudos to the team for continuing to make Visual Studio relevant to the state of the market and a first class IDE!
Our teams have completely switched over to Bower from NuGet for client-side packages for several months now. We're using Gulp as our build tool for Angular apps with a MVC and Web API backend. After some blood, sweat and tears we were able to bypass our reliance on System.Web.Optimization for bundling, which had given us all sorts of pain.
I wrote quite the essay on our experiences in the form of a comparison of Bower vs. NuGet that your team may also find helpful: Why Bower is better than NuGet.
Kudos to the team for continuing to make Visual Studio relevant to the state of the market and a first class IDE!
Awesome! These features will bring me back to VS from other editors.
Huge fan of integration of these kinds of tools into Visual Studio.. now I'd love some extensibility in terms of integrating some alternative tools. Specifically in my case, PVC build - pvcbuild.com.
Good work to everyone putting in the hours to make this happen, we appreciate it!
Good work to everyone putting in the hours to make this happen, we appreciate it!
@Brandon, the Task Runner Explorer is completely extensible. In fact, both Grunt and Gulp are added using the public extensibility API of the Task Runner Explorer. Any task/target based system (fez, broccoli, pvcbuild) can be added in the same way with same support. We haven't documented the API yet, since it's still subject to change, but we will.
@Mads can this be extended to things like jekyll? Jekyll lacks an editor. You have to build everything in the command line. I've been thinking of building and editor from scratch, but extending this as visual studio plugin seems better. I've also thought of the possibility of creating an editor based on the Visual Studio Shell.
Any thoughts?
Any thoughts?
Awesome feature guys, having switched to Angularjs as our main JavaScript library I find myself using npm and Grunt more and more. This feature is very welcome indeed!
Great!
It happened to me to ask for gulp and it's module support in visual studio a few months back. After a while I was notified that the development was started and now here it is.
Making a product every day better and empowering the community with one stone! Thanks.
It happened to me to ask for gulp and it's module support in visual studio a few months back. After a while I was notified that the development was started and now here it is.
Making a product every day better and empowering the community with one stone! Thanks.
Are there plans to migrate Javascript Intellisense from the _references.js convention of today?
Awesome news. I might have to dust off my front end chops. I also might have to get on the VS2014 train.
This should be quite awesome. Being able to associate a VS build with a Gulp process. WIN!
I just upgraded from VS2010. While VS2013 seems nice but it is getting pretty bloated. My web site in 2010 compiled and was presented in 5 seconds. 2013, I have to wait 15 seconds. The default MVC project has tons of dll's referenced and all that takes time to load. I will have to check and see which of the dll references I can drop as it seems like over kill and unnecessary. The new Identity model is awful. Way too abstract for the common man to comprehend. I just need simple forms authentication with roles. Identity is a monster of overkill. VS2013 and the default project bloat is a bit of a punch in the face from VS2010. VS2013 and all the fantasy projects might be fun for a college professor and theoretical mindset, but a corporate programmer has too learn way to much and by the time they learn it, it changes. Its all about productivity. I've lost some of mine.
One issue I'm having with the grunt functionality is that I setup the grunt files up at the solution level, not at the project level. The plugin assumes the gruntfile is at the project level, so it doesn't detect any tasks yet. The Task Runner Explorer should list "Solution" in the Project dropdown, and support right-click actions from the solution as well as the project.
The workaround currently is to create an empty project at the root of the solution directory specifically for the purposes of grunt task detection, but I'd prefer not to have to do that.
The workaround currently is to create an empty project at the root of the solution directory specifically for the purposes of grunt task detection, but I'd prefer not to have to do that.
These features are really impressive, probably I'll use Visual Studio 2014 even for non-Microsoft projects.
@Jean-Baptiste, please use the comments here or the discussion section on the VS Gallery for reporting bugs and giving feedback. http://visualstudiogallery.msdn.microsoft.com/8e1b4368-4afb-467a-bc13-9650572db708/view/Discussions
Sharing some pains on the subject of front-end workflow and VS:
I've been out of Visual Studio for front-end development for half a year.
It all started when I had a node_modules directory some kilometers deep, and visual studio started giving me errors when I tried to commit. I had to switch to the command line for that. (Update 3 came out and I still face this problem)
Since I was stuck to the commandline for commits, I slowly started incorporating all of the commandline flow. Npm -> yeoman -> bower -> gulp -> livereload. Development was FAST, but VS's intellisense for javascript was actually hurting me more than helping me. It was slow and innacurate and most suggestions were irrelevant. I finally switched to sublimetext and found it fast and satisfying.
What VS needs before I can go back to it for font-end:
a) Fix the path depth bug on GIT
b) Make intellisense better for JS
c) Be overall faster
What IS missing in my workflow is CI on TFS. I managed to get Chutzpah running jasmine tests on every build, but haven't had a look at integrating gulp into webdeploys from TFS.
I've been out of Visual Studio for front-end development for half a year.
It all started when I had a node_modules directory some kilometers deep, and visual studio started giving me errors when I tried to commit. I had to switch to the command line for that. (Update 3 came out and I still face this problem)
Since I was stuck to the commandline for commits, I slowly started incorporating all of the commandline flow. Npm -> yeoman -> bower -> gulp -> livereload. Development was FAST, but VS's intellisense for javascript was actually hurting me more than helping me. It was slow and innacurate and most suggestions were irrelevant. I finally switched to sublimetext and found it fast and satisfying.
What VS needs before I can go back to it for font-end:
a) Fix the path depth bug on GIT
b) Make intellisense better for JS
c) Be overall faster
What IS missing in my workflow is CI on TFS. I managed to get Chutzpah running jasmine tests on every build, but haven't had a look at integrating gulp into webdeploys from TFS.
Excellent work! Are there any plans to integrate these tools more seamlessly with the TFS build process?
@Jay, yes there is, but only for Visual Studio "14". In earlier versions of VS you can simply use the post build script feature already in place
I am getting package intellisense for bower package names, but not version numbers.
When I attempt to "update package" I am getting an error that 'bower' is not recognized as an internal or external command.
I have the Nuget Bower package installed (version 1.3.5.2), but am new to Bower. I suspect I'm missing some simple setup step. Can you provide additional setup information in the article?
When I attempt to "update package" I am getting an error that 'bower' is not recognized as an internal or external command.
I have the Nuget Bower package installed (version 1.3.5.2), but am new to Bower. I suspect I'm missing some simple setup step. Can you provide additional setup information in the article?
@Bower newbie,
It sounds like you don't have bower installed in global scope. Run this command "npm install -g bower" from anywhere. That will add the global bower command line support needed. I'm not sure the NuGet package does exactly the same thing as the official bower npm package does.
Also, the bower REST API doesn't allow for retrieving the version numbers. We're looking into using alternative APIs to get them.
It sounds like you don't have bower installed in global scope. Run this command "npm install -g bower" from anywhere. That will add the global bower command line support needed. I'm not sure the NuGet package does exactly the same thing as the official bower npm package does.
Also, the bower REST API doesn't allow for retrieving the version numbers. We're looking into using alternative APIs to get them.
I am so excited about this!
This is a huge step in the right direction for Visual Studio, hooray \o/
This is a huge step in the right direction for Visual Studio, hooray \o/
installed yeoman, it has a node package that exceeds windows path size.
crazy that it's 2014 and we still have this problem in windows.
I applaud making these tools accessible, I use them often, at same time, why not make your own platform do what needs to be done, ie:
improvements:
take your bundler, include capabilities like 'ng-annotate'. I should be able to include in the bundler pipeline all the goodness you get from grunt, etc... I shouldn't need to pop out into a completely different tech stack when working in VS. And no -'right clicking with extensions' doesn't work on large teams, it needs to be baked in. We need things like JSHint to be a part of the build process. Yes, you can install extensions, but if one dev doesn't have the extension, they don't get build errors through JSHint.
So basically the functionality Mads is doing with express is awesome... it's too bad though this type functionality isn't a norm in VS.
Lastly, to stay in touch with the frameworks - Angular is one of the most used - why not more attention to it ? I know Steve did a great job with Knockout, but it's not nearly as popular as Angular. I've seen some templates for Angular with Visual Studio, but it's so convoluted with 'mvc server side' stuff that I tend to start with a blank project and spend over an hour getting everything setup for a client side solution that uses WebAPI. And then running grunt build tasks, I spend another couple of hours setting up all the min paths, etc.. then when done, need to figure out how to, ie. deploy this to Azure... which seems to only like asp.net mvc vanilla deployments.
Much to do! Good progress... but dreadfully slow
crazy that it's 2014 and we still have this problem in windows.
I applaud making these tools accessible, I use them often, at same time, why not make your own platform do what needs to be done, ie:
improvements:
take your bundler, include capabilities like 'ng-annotate'. I should be able to include in the bundler pipeline all the goodness you get from grunt, etc... I shouldn't need to pop out into a completely different tech stack when working in VS. And no -'right clicking with extensions' doesn't work on large teams, it needs to be baked in. We need things like JSHint to be a part of the build process. Yes, you can install extensions, but if one dev doesn't have the extension, they don't get build errors through JSHint.
So basically the functionality Mads is doing with express is awesome... it's too bad though this type functionality isn't a norm in VS.
Lastly, to stay in touch with the frameworks - Angular is one of the most used - why not more attention to it ? I know Steve did a great job with Knockout, but it's not nearly as popular as Angular. I've seen some templates for Angular with Visual Studio, but it's so convoluted with 'mvc server side' stuff that I tend to start with a blank project and spend over an hour getting everything setup for a client side solution that uses WebAPI. And then running grunt build tasks, I spend another couple of hours setting up all the min paths, etc.. then when done, need to figure out how to, ie. deploy this to Azure... which seems to only like asp.net mvc vanilla deployments.
Much to do! Good progress... but dreadfully slow
These tools should be out of site and out of mind in VS. We should not have to know what the underlying tool is; just a category of the tool and an enabled/disabled switch is enough for most developers.
These convince tools have a short lifespan and less utility value in knowing them in detail.
A budding development issue is picking tools, third party libraries and development environment so that they last longer than the expected lifespan of the software solution to be developed. We've been hit by dead, near dead and especially zombie tools in 3 different $1 million+ software applications in the last 2 years. Our procurement team vets new tools for licensing issues, strength/longevity prospects and cost. The technical team will vet them for functionality, suitability and overall quality (hint: no documentation created by reflector as done by some major UI controls vendors).
This rules out many of the perpetual alpha/beta quality libraries.
Complicated sounding? Yes, if one develops throw away web sites and apps. No, if one is making a $2 to $3 million purchase of a new system expected to last for 7+ years.
These convince tools have a short lifespan and less utility value in knowing them in detail.
A budding development issue is picking tools, third party libraries and development environment so that they last longer than the expected lifespan of the software solution to be developed. We've been hit by dead, near dead and especially zombie tools in 3 different $1 million+ software applications in the last 2 years. Our procurement team vets new tools for licensing issues, strength/longevity prospects and cost. The technical team will vet them for functionality, suitability and overall quality (hint: no documentation created by reflector as done by some major UI controls vendors).
This rules out many of the perpetual alpha/beta quality libraries.
Complicated sounding? Yes, if one develops throw away web sites and apps. No, if one is making a $2 to $3 million purchase of a new system expected to last for 7+ years.
This is a great improvement! One more feature is missing which prevents me to do front-end development in Visual Studio - directory-based projects:
twitter.com/koistya/status/474242971781824515
I would love if Visual Studio would support project layouts similar to these:
github.com/angular/angular-seed ..or.. github.com/kriasoft/react-seed
(no .proj files, no /bin /obj ect. folders, at least not in the same folder with source files, F5 would start Gulp build process... etc.)
twitter.com/koistya/status/474242971781824515
I would love if Visual Studio would support project layouts similar to these:
github.com/angular/angular-seed ..or.. github.com/kriasoft/react-seed
(no .proj files, no /bin /obj ect. folders, at least not in the same folder with source files, F5 would start Gulp build process... etc.)
Konstantin - I believe that (directory based projects) is coming in VS "14" http://www.asp.net/vnext
Is there any step by step guide to run sample front end project from GitHub in Visual Studio using those tools ? With list of all the the dependencies like Node, etc.
I'm starting to wonder whether the VS and ASP.NET teams could get into an existential crisis over all this pushing towards open source community-backed libraries and tools.
Client-side libraries such as Angular are putting question marks on parts of ASP.NET MVC and its view engines.
Now for front-end NuGet is being pushed aside by bower, MSBuild by Grunt and Gulp.
Even TypeScript has to make its case against ES6/7 (with Traceur) and Dart.
The server side .NET stack still stands ground thanks to C#, Web API, Entity Framework, and others, but for how long? We can hear Node.js and NoSQL knocking at the door more and more.
What I appreciate as a developer is to get something opinionated and coherent while providing best-of-class productivity and features. I don't want to have to roam around for the latest fashionable frameworks and tools and figure out how to make them interact. It gets too boring too quickly to have to match expectations of fellow developers in terms of technology, get paralyzed by choice, risk betting on technology with no future, when all you want is to get the job done for the client and make it maintainable for the next 5 to 10 years.
I hope that this is taken into consideration for the added value that the VS team is striving for with future releases.
Client-side libraries such as Angular are putting question marks on parts of ASP.NET MVC and its view engines.
Now for front-end NuGet is being pushed aside by bower, MSBuild by Grunt and Gulp.
Even TypeScript has to make its case against ES6/7 (with Traceur) and Dart.
The server side .NET stack still stands ground thanks to C#, Web API, Entity Framework, and others, but for how long? We can hear Node.js and NoSQL knocking at the door more and more.
What I appreciate as a developer is to get something opinionated and coherent while providing best-of-class productivity and features. I don't want to have to roam around for the latest fashionable frameworks and tools and figure out how to make them interact. It gets too boring too quickly to have to match expectations of fellow developers in terms of technology, get paralyzed by choice, risk betting on technology with no future, when all you want is to get the job done for the client and make it maintainable for the next 5 to 10 years.
I hope that this is taken into consideration for the added value that the VS team is striving for with future releases.
Jacob, here is a project to play with "Facebook React Starter Kit" for Visual Studio, it has node modules and Gulp pre-configured. So you would just run > npm install; bower insta; gulp build -- to build a project:
http://visualstudiogallery.msdn.microsoft.com/d65d6b29-6dd7-4100-81b1-609e5afce356
http://visualstudiogallery.msdn.microsoft.com/d65d6b29-6dd7-4100-81b1-609e5afce356
Awesome! This is really a cool stuff with .Net framework. really great implementation by Micro Soft. It is very nice to have the feature like when you want the build status and build information with a helpful tool like this.
@Steve, Angular is our #1 js priority for VS 14. You'll start seeing improvements in VS2013 Update 4 already.
@Konstantin Tarkus, folder based web projects have been possible since VS2005 using the Website Projects. There's no project files, just a folder. True generic folder based project support is in the works...
@Konstantin Tarkus, folder based web projects have been possible since VS2005 using the Website Projects. There's no project files, just a folder. True generic folder based project support is in the works...
Looks great! But.. Who need js minification in vosual studio, but not on CI server?
Its possible to use this integration in msbuild?
Its possible to use this integration in msbuild?
"I'm starting to wonder whether the VS and ASP.NET teams could get into an existential crisis over all this pushing towards open source community-backed libraries and tools."
I completely agree with this, Antoine... it is getting to the stage where there seems to be a constant desire to implement the latest open source fad or competitors latest idea, instead of providing a consistent stack on the MS platform, which has some areas that really need attention.
Now MS devs have been initially pushed towards jQuery, then Knockout.js, now probably Angular.js... a bit of TypeScript here and there to offset the fact that these are all weakly typed languages/frameworks that are either sponsored by competitors, or have a very limited lifespan... now Bower, Grunt, npm, Node.js while using NuGet, PowerShell, MSBuild ... *just to manage what external libraries are included and built* (never mind the whole OWIN ´keep adding bits and see if it works´ approach we have to face in vNext, with its open source naming convention, change from XML to JSON). Its becoming a jigsaw puzzle of ´what should I use now, how do I include it, what do I debug first, how the hell do I unit test this, oh god what do I do to deploy this´.
Far from being a step forward, I see this as a problem. We don´t all have the luxury of spending 12 hours a day reading and learning what the latest release of JavaScript framework X (and its 200 forks or competitors) offers and getting paid for it. Some of us actually have to deliver complex projects for a living, that consist of more than ´hello world´ and are intend to stay in Production for more than a week.
Front end devs are constantly changing their toolkit - try working with a couple of them on the course of a 6 month project - it is a constant fight to stop them from switching to some latest fad, rather than getting them to deliver what was specified.
Its basically back to coding about 15 years ago, with everything was custom created for the immediate needs, changed from one project to the next, and was impossible to coordinate between teams.
I completely agree with this, Antoine... it is getting to the stage where there seems to be a constant desire to implement the latest open source fad or competitors latest idea, instead of providing a consistent stack on the MS platform, which has some areas that really need attention.
Now MS devs have been initially pushed towards jQuery, then Knockout.js, now probably Angular.js... a bit of TypeScript here and there to offset the fact that these are all weakly typed languages/frameworks that are either sponsored by competitors, or have a very limited lifespan... now Bower, Grunt, npm, Node.js while using NuGet, PowerShell, MSBuild ... *just to manage what external libraries are included and built* (never mind the whole OWIN ´keep adding bits and see if it works´ approach we have to face in vNext, with its open source naming convention, change from XML to JSON). Its becoming a jigsaw puzzle of ´what should I use now, how do I include it, what do I debug first, how the hell do I unit test this, oh god what do I do to deploy this´.
Far from being a step forward, I see this as a problem. We don´t all have the luxury of spending 12 hours a day reading and learning what the latest release of JavaScript framework X (and its 200 forks or competitors) offers and getting paid for it. Some of us actually have to deliver complex projects for a living, that consist of more than ´hello world´ and are intend to stay in Production for more than a week.
Front end devs are constantly changing their toolkit - try working with a couple of them on the course of a 6 month project - it is a constant fight to stop them from switching to some latest fad, rather than getting them to deliver what was specified.
Its basically back to coding about 15 years ago, with everything was custom created for the immediate needs, changed from one project to the next, and was impossible to coordinate between teams.
Have been 'forcing' .Net devs to use grunt/bower/npm for some time now. It pays a whole heap with a bit of work. Its great I can now even silence the fewmembers of the, "yeah this is cool, but it can't be that good its not integrated into visual studio" club!!
Hi Scott,
You guys are moving too fast. I can barely keep up. It feels like I spend more time learning new things that you guys are putting out than actually programming.
But I must say, programming in .NET is still my favorite thing to do.
Thanks a bunch for all the hard work you guys are putting in helping us build awesome apps!
You guys are moving too fast. I can barely keep up. It feels like I spend more time learning new things that you guys are putting out than actually programming.
But I must say, programming in .NET is still my favorite thing to do.
Thanks a bunch for all the hard work you guys are putting in helping us build awesome apps!
Man, I've wanted this for so long. It's a relief to know that the Visual Studio team has been listening.
This worked right out of the box with my complex solution that uses Gulp to sort and organize the redistributable files that go between 6 different projects in a very picky way. Beautifully done. Absolutely beautiful!
Damn, double comment. Oh well.
I also want to add, the gulpfile doesn't need to be in a visual studio project for this to work. I have my gulp stuff outside of my projects, just included in the solution as "virtual files". They still worked just fine!
I also want to add, the gulpfile doesn't need to be in a visual studio project for this to work. I have my gulp stuff outside of my projects, just included in the solution as "virtual files". They still worked just fine!
Awesome, I was waiting for a solution like this, until now i have to remember the steps before build.
@Mansoor
On the web you are not alone, so you have to be the part of most communities otherwise you will be obsolete. Make your habit to at least visit asp.net and take a view on front page articles on daily basis after few weeks you will knew where the community is going and what you need to do to follow.
@Mansoor
On the web you are not alone, so you have to be the part of most communities otherwise you will be obsolete. Make your habit to at least visit asp.net and take a view on front page articles on daily basis after few weeks you will knew where the community is going and what you need to do to follow.
Antoine, @Perambulator couldn't agree more. I don't want grunt, bower, npm, and other golum-golum tools that can't be relied on the long term, and I don't have the time to keep up with the latest version or installation incompatibilities between developers stations. I want professionally build libraries that I can relied on for the years to come, like the old good MS was producing.
The `I don't have time` excuse is so looser.
We all have problems, fact is:
I don't care, no one does.
You don't have time?
You are behind.
Choose your league wisely. Whatever your choice is, it's ok. No need to blame about that.
We all have problems, fact is:
I don't care, no one does.
You don't have time?
You are behind.
Choose your league wisely. Whatever your choice is, it's ok. No need to blame about that.
@Bart: You are obviously not very familiar with requirements of enterprise development scenarios. While "don't have time" is a simplification, it is true in professional development environments where long term reliability and supportability by first party (vendor of the tool) is super important and shift in tooling easily can costs double digit or even triple digit millions.
@Andi, the support for Grunt/Gulp/Bower/npm will be optional. You don't have to use it if you don't want/need to.
These extensions should obviously be available in any project type. There's no reason to not allow integrating of Gulp or Grunt into the standard MSBuild pipeline.
In fact, this extension should integrate into the standard MSBuild pipeline.
In fact, this extension should integrate into the standard MSBuild pipeline.
And while you guys are on it, we need project references for all this new stuff. I need to be able to create a JavaScript project that creates .js file artifacts, that can be added to other projects by the mere addition of a project reference.
Mads, thank you very much for this (and Scott for bloggin about it)! This is a huge step forward and very helpful. I'm developing a large Ember.js application and I love the fact that I can integrate grunt in VS.
Some questions:
1. I run my grunt build after the .NET build. Is there a way to integrate the task runner output in the standard VS output console?
2. I'm using a publishing profile for deployment. Is there a way to "wait" for the task runner result before compiling or deploying?
Thank you,
Stefan
Some questions:
1. I run my grunt build after the .NET build. Is there a way to integrate the task runner output in the standard VS output console?
2. I'm using a publishing profile for deployment. Is there a way to "wait" for the task runner result before compiling or deploying?
Thank you,
Stefan
@Jerome, the plan is to make it work in all project types. Because almost all project types are implemented differently, we weren't able to support them all in this initial release.
Integrating into the MSBuild pipeline out of the box is something we are investigating. It's no where nearly as simple as it sounds. You can however easily do that already by calling "grunt build" from the project's post build script.
@Stefan,
1. No, this is not currently possible. I like the idea though, so I've added it to my todo items to look into.
2. Not currently, however it is something we are looking into for upcoming releases. To do it right, we may have to hook into the MSBuild pipeline and that is not that simple (see reply to Jerome above)
Integrating into the MSBuild pipeline out of the box is something we are investigating. It's no where nearly as simple as it sounds. You can however easily do that already by calling "grunt build" from the project's post build script.
@Stefan,
1. No, this is not currently possible. I like the idea though, so I've added it to my todo items to look into.
2. Not currently, however it is something we are looking into for upcoming releases. To do it right, we may have to hook into the MSBuild pipeline and that is not that simple (see reply to Jerome above)
Awesome! I guessed that both things aren't trivial. Thank you again Mads!
Do I need to install node/npm separately, or am I just doing something wrong?
I get "'npm' is not recognized as an internal or external command" when I try to Right click -> NPM Install Packages.
I have installed all the vsix packages mentioned, on my VS 2013 Update 3.
I get "'npm' is not recognized as an internal or external command" when I try to Right click -> NPM Install Packages.
I have installed all the vsix packages mentioned, on my VS 2013 Update 3.
@Martin yes, if you download the windows installer for nodejs.org you'll get both node and npm globally. Right now there's a bug, you need to create an ~/AppData/Roaming/npm directory.
----
I've been using node/npm for several years now. I also started using build/postbuild for node tools to build my less/css files and min/merge/uglify my js for several years as well. I have two projects I am converting from using chirpy now (since that tool doesn't work in VS2013).
Node has served me very well, and honestly when I have to work in VS and with C# it's often a bit of frustration compared to how I now develop with node. It takes a different mindset.
Also, I really wish that VS had an "empty" or "bare" project for stuff that is similar to a web project, where there is no compile step (other than build/postbuilds specified), and has a project.ignore file for convenience. This way you could use VS to edit projects that will be built with other systems and work within a given solution. This would have been useful for years before an actual node project type was available.
----
I've been using node/npm for several years now. I also started using build/postbuild for node tools to build my less/css files and min/merge/uglify my js for several years as well. I have two projects I am converting from using chirpy now (since that tool doesn't work in VS2013).
Node has served me very well, and honestly when I have to work in VS and with C# it's often a bit of frustration compared to how I now develop with node. It takes a different mindset.
Also, I really wish that VS had an "empty" or "bare" project for stuff that is similar to a web project, where there is no compile step (other than build/postbuilds specified), and has a project.ignore file for convenience. This way you could use VS to edit projects that will be built with other systems and work within a given solution. This would have been useful for years before an actual node project type was available.
A small heads up for those looking to jump into these.
If you need to compile your own LESS mixings into Bootstrap using Grunt, then forget about Bower. You need to clone the full Bootstrap repository from Github and install dependencies with npm.
You can then register your own copy of Bootstrap as a local package (file:///) with a Bower project, if you want.
If you need to compile your own LESS mixings into Bootstrap using Grunt, then forget about Bower. You need to clone the full Bootstrap repository from Github and install dependencies with npm.
You can then register your own copy of Bootstrap as a local package (file:///) with a Bower project, if you want.
Did anyone try bower together with TFS GIT, I am having not much success. I did the protocol configuration to use http:// instead of git:// but always receive and error when doing a bower install git://tfs...#version.
This is great. I'm on a project using AngularJS on a .Net backend. What would be wonderful is if I could execute grunt for my testing from a VS Test project. It doesn't look like the Task Explorer works in a VS Test project, though I can right click in the Grunt file and run my tests and the output shows up in the output window. So at least it looks like the Grunt file runs properly.
Great work guys! Thanks :)
Question: does anyone know if there is an VS extension or starter project based on ng-boilerplate and Typescript?
Question: does anyone know if there is an VS extension or starter project based on ng-boilerplate and Typescript?
I am using the bindings to bind certain tasks to the Before and After build events. However it looks as if these bindings are executed in an asynchronous manner. I can see both the before and after build running at the same time in the task runner explorer.
Comments are closed.