Geeks With Blogs
Doug.Instance Improving the world one post at a time

Open source tools and frameworks are great, but when you use frameworks like AngularJS and LESS you can end up with a many files that get compiled down to just a few.  Keeping these files separate is good for development and debugging so it is important to keep all of the original source files under source control, but you don’t want them published to your production web site.

I am a fairly recent convert to AngularJS but when I took the plunge I was surprised that even with its massive popularity and obvious synergy with .Net, it was difficult to find guidance on exactly how best to setup a project in Visual Studio.  Once you drink the Angular Kool-Aid, you quickly learn that it tastes best with a side of node.js, Grunt/Gulp, etc.  I am also a big fan of Bootstrap so my CSS usually starts with the Bootstrap LESS source.  Using the full-blown version of Visual Studio, the Web Essentials extension can duplicate many of the things you would do using node.js such as compiling/minfying LESS and concatenating/minifying JavaScript.  Unfortunately Web Essentials isn’t available for the Express editions of Visual Studio so people using this great, free tool need a different alternative.  Also, if you want to contribute to one of the open source projects that use node.js, you will need to be able to use these tools but you may want to use them with VS.

For those of you who like spoilers, most of the “magic” that I have learned can be summed up with the following structure:

  • ProjectName [Solution]
    • ProjectName.Web [Web Application]
      • src [Web Site]
    • ProjectName.Web.Tests [Web Application Tests]

This structure makes it easy to keep all of your source organized with only “production” code in your web application.  I will answer “how” and “why” in the rest of this post. Like all good ideas (and yes, I recognize I just complimented myself), this setup was born out of necessity and presented itself after trying to do it the “normal” way.  So let’s walk through the setup and I’ll point out the key decision points.

Just like most of my favorite walkthroughs, this starts with File->New Project.


There are some subtle nuances here.  Note that the “Create directory for solution” checkbox is checked.  This sort of comes down to preference but you do get some quirks in the file structure if this is turned off.  Namely your test project (which we will create in the next step) will be in a directory under your web project.  Another thing you will note is my naming convention.  I have been using this sort of structure for a long time and it serves me pretty well.  Many examples you see will have a simple name like “BobsMvcDemo” and therefore that is the namespace.  If you are reading this you probably use .Net and are used to the massive namespace structure.  Isn’t it logical to use a similar structure in your own code?  I’ve talked a little more about this philosophy in other posts but just understand that “OpenToolsSample” is my root namespace and I add “.Web” to the project name which also adds that to the namespace.  Note that the solution name is just the root namespace or “OpenToolsSample”.

Next let’s create our web application and test project:


My preference is to create an empty with MVC, Web API and unit tests checked.  If this is your first MVC app, you might want to select “MVC” and check the Web API and unit tests block.  That will give you a project that will run right out of the box along with some good code and helpful NuGet packages to get you started.  However, I find it faster to add the things I want than to remove those that I don’t.  So if you know what your or doing (or if you just trust me), you can just keep following along to get a basic app up and running.

Once you hit OK you will see your web application and test projects.  Make sure your web application is set as the start-up project (right-click on the project in the Solution Explorer and select “Set as StartUp Project”).  Your solution should now look something like this:


If take a look at a typical open source project, you will usually see a package.json file in the root folder that can be used to configure node.js and modules.  You can install node.js in the root and all modules will be installed there as well.  The advantage of this is that changes to node.js and any modules you use don’t have to be incorporated until you want them to be.  You can have multiple projects all with different versions of node.js and modules without having to worry about conflicts.  Your configuration packages like Grunt (my preferred task runner), typically live in your root folder too.  Node and Grunt configuration is critical to building your application so it needs to be in source control (i.e. your Git repository).  It isn’t necessary to keep the modules themselves in source control since they can be installed from the configuration.  Therefore my recommendation is that you simply put your package.json and any other node configuration files (i.e. Gruntfile.js) in the root of your web application project.

So what about the rest of your code?  Regardless of the JavaScript framework you choose (Angular, Knockout, Ember, etc.), you will likely want to keep your source organized in multiple files.  The same is true for LESS.  Typically this folder is called “src” or “app”.  You could add this folder to your existing web application project (as I did) but then the default behavior would be to publish this source when you publish your web project.  There are a lot of ways to deal with this, but the one I settled on is to use a “web site” outside of your “web application” project so let’s add a new web site called “src” to our solution in the same location you would normally put this folder (under your web application project folder):



Now our solution now looks like this (note I include package.json and Gruntfile.js for reference):


If I show all files from the web application project, you see that the “src” folder is actually under the physical path of the web application:


You can now add your solution and all associated projects to source control using your preferred source control provider (I use the free Team Foundation Server Express, but Git is also supported by VS Express).  You can put your node/Grunt/Gulp/etc. configuration in your web application as shown above with package.json and Gruntfile.js.  NuGet packages (AngularJS, Bootstrap, jQuery, etc.) would typically go in your web application project’s “Content” (for CSS) and “Scripts” (for JavaScript) folders so you can point your output from Grunt/Gulp there as well.  Then, following “normal” ASP.Net conventions, you can publish only your “production” code with your web application.  When you install node modules with “npm install”, the “node_modules” folder will be under your web application, not your “src” web site so that folder can be excluded from source control.

In my next post I will go into some specific examples using Grunt to concatenate and minify AngularJS source and to compile and minify LESS source.  I will also highlight some considerations for setting up AngularJS apps with MVC and Web API.

Posted on Sunday, October 5, 2014 9:19 PM | Back to top

Comments on this post: Setting Up node.js with Visual Studio Express 2013 for Web

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Doug Lampe | Powered by: