ASP.NET 5 (formerly known as ASP.NET vNext), along with .NET Core, is Microsoft’s ground-up rewrite of the .NET Framework. It is designed specifically for modern cross-platform web-application development and involves a number of breaking changes and new concepts that the .NET developer will need to be aware of.
Configuration
The first major change that most developers will notice straight away is that there is are more *.config files. ASP.NET 5 does away with xml based configuration files, replacing them with a JSON based approach. For example web.config has been replaced by config.json. Another key change, is that we now have access to environment variables as part of our configuration. This in itself is a major departure from the traditional ASP.NET model, and one which does require some careful consideration.
Package Management
The next major change is the increase in the number of package managers that you now need to be aware of. Gone are the days where all of your ASP.NET application dependencies are managed by NuGet. ASP.NET 5 has a more defined separation of your backend dependencies and your frontend dependencies.
NuGet: For .NET Framework and .NET packages (Backend)
It isn’t exactly a secret that managing Javascript or client side packages with NuGet in the traditional ASP.NET model was a pain. Moving forward with ASP.NET 5, NuGet is now only used to manage .NET Framework or .NET packages.
Node Package Manager (NPM): For frontend build dependencies (Frontend)
Items such as Bower (our preferred Javascript client library package manager), Gulp and Typescript and all managed via NPM. This allows us to take advantage of the ever growing NodeJS ecosystem to accelerate our ASP.NET 5 frontend development. Adding Node packages into our ASP.NET 5 solutions is as simple as editing the packages.json file in Visual Studio (complete with IntelliSense and package name completion).
Bower: For client side frameworks & libraries (Frontend)
Bower from Twitter, is a purpose built package manager for javascript and client side client libraries. As with NPM, adding javascript packages to our projects is a simple as editing a JSON configuration file. In this case bower.json. Again, Visual Studio provides IntelliSense and package name competition out of the box.
Front end build automation / task runners
Gulp and Grunt are Javascript front end build automation tools, or task runners depending on how you want to look at it. These tools allow us to script our front end build process in a simplified, maintainable and repeatable way. Visual Studio 2015 ships with support for both Gulp and Grunt.
Project Structure
ASP.NET 5 makes some significant changes to the classic project structure that we are all familiar with. The largest change is the introduction of the wwwroot folder, which is where all of your static assets are stored and served from, files outside of the wwwroot folder are inaccessible. This change provides a higher degree of separation between files that need to be served to a requesting client and your server side code. The wwwroot folder is mapped directly as the root folder of your deployed application.
Would you like to learn more about ASP.NET 5?
SSW Dev Superheroes Adam Stephensen and Duncan Hunter will be covering this and more in their two day ASP.NET 5 and Angular Superpowers Tour. Stopping in Melbourne (16th – 17th March) Brisbane (21st – 22nd March) and Sydney (31st March – 1st April).
Video Transcription
Adam Stephensen: Hi. I’m Adam Stephensen. I’m a solution architect at SSW and the principle mentor at FireBootCamp.
I’ve just finished my first application using Visual Studio 2015, MVC-6, and AngularJS. I’m so excited to building enterprise web apps leveraging all the front end best practices developed by the java-script community, and using my C-sharp, MVC, and Web API skills for the back end, and doing it all with the productivity of Visual Studio.
I’ve got to say, though, there’s definitely a lot of pain involved. Moving to MVC-6 and Visual Studio 2015 is a massive change. It’s as big a change as changing from Web Forms to MVC. There’s a lot of new concepts to get your head around, technologies to learn, and best practices to discover.
There are major changes to the solution structure which we will have a look at in a future video. We used to have XML config files. These are gone now. In their place we’ve got JSON based config files. For example, web.config has been replaced by config.json. We only use NuGet now for getting .net framework base packages. We use Bower for funding packages, and NPM for no packages.
Now instead of getting [inaudible 00:01:08] library’s like twitter boot stamp or NuGet, we use Bower as a client style package manager. To add clients on packages we simply add them to bower.json. The other package managing you need to get your head around is NPM, no package manager. We use packages.json to configure which no packages were going to use for tasks like bundling, minification, compiling type script and less, and other frontend build processes.
Which brings me to my next point. We now need a build process for our frontend, not just our backend. A typical frontend build process involves compiling less to CSS, compiling type script to JavaScript. Building source maps in JavaScript reference files. Running JavaScript linked as a unit tests. Bundling and morphication. To do this we use a JavaScript task file like Grunt or Gulp. In ASP.NET 5 we now have the concept of the dub dub root folder. This is where all of our static files go. It gives a clear separation of the code files, and our study files. It gives us performance improvements and better security as only files in the dub dub root folder can downloaded directly.
Okay, yeah. It’s all a bit much. It took us weeks of working with the new stack to work out how everything fit in together, and our best practice is still evolving. But we want to help you out by sharing what we’ve learned so far. So stay tuned, and we’ll be putting together lots of great content to help you get up to speed as easily as possible, and get shipping awesome apps on the lines of technologies.
Thanks for listening, and please drop me a tweet with your feedback.
About the speakers
Adam Stephensen
Adam Stephensen is a Solution Architect at SSW with a decade of experience performing needs analysis, designing and building scalable, database-driven, distributed enterprise solutions incorporating web and windows interfaces.