ASP.NET 5 is the most significant new release of ASP.NET in the history of the ASP.NET framework. It has released with ASP.NET MVC 6 which been designed for cloud-optimized applications. The runtime automatically picks the correct version of the library when our MVC application is deployed to the cloud. Here will be understanding what makes ASP.NET MVC 6 more outstanding than its previous version by creating sample application and comparing project solution structure between them. The best way to learn what’s new in any technology is to compare with its previous version. Well we have many difference(s) between ASP.NET MVC 6 and ASP.NET MVC 5 in solution structure itself, lets explore them without code been written.

What Makes ASP.NET MVC 6 More Outstanding Than Its Previous Version?

Single aligned web stack for MVC 6 and Web APIs

ASP.NET MVC 6 now has single aligned web stack for MVC 6 and Web API. Image below shows check box are GREYED out for MVC and Web API while MVC 5 gives option to add Web API. While ASP.NET MVC 5 gives us option of choosing MVC or Web API or both while creating web application. It was because web stack for MVC 5 and Web API was not the same.

Project(Solution) Structure Changes

If you see ASP.NET MVC 6 solution explorer on right hand side, there is no Web.config, Global.asax. Then, how it deals with configuration settings, authentication and application start specific code execution. “Project.json”, “Config.json” are some files which does those work of missing files from ASP.NET MVC 5. There are many changes if we examine folder by folder.

ASP.NET MVC 6 targets Full .NET and .NET Core

We have being working on full .NET framework, it is amazing experience till now and will continue to be. Then what is .NET core? .NET Core is a cross-platform implementation of .NET that is primarily being driven by ASP.NET 5 workloads. Now we can develop ASP.NET MVC 6 or ASP.NET 5 against .NET core/ Full .NET and run in either Windows or Linux or Mac. Not only we can develop in Windows OS but also in Linux, Mac using Visual Studio Code IDE or any other IDE. Take a look at this image:

wwwroot is now place for static files

The wwwroot folder represents the actual root of the web app when running on a web server. Static files like config.json, which are not located in wwwroot will never be accessible, and there is no need to create special rules to block access to sensitive files. These static files might be plain HTML, Javascript, CSS, images, library etc. In addition to the security benefits, the wwwroot folder also simplifies common tasks like bundling and minification, which can now be more easily incorporated into a standard build process and automated using tools like Grunt.

“wwwroot” name can be changed in project.json under “webroot”: “Demowwwroot”

In addition to the security benefits, the wwwroot folder also simplifies common tasks like bundling and minification, which can now be more easily incorporated into a standard build process and automated using tools like Grunt.

New approach to Server side & client side dependency management of packages

Any .NET developer would be familiar that References folder holds all DLLs, Nuget packages for particular .NET Framework, While in ASP.NET 5 development in Visual Studio we can target DNX 4.5.1 and DNX Core 5.0. Leverage the experience of working in Visual Studio IDE and deploy ASP.NET 5 applications either in Windows, Linux or Mac using DNX Core 5.0. Its Server side management of dependencies.

Client side dependency management is more important because client side has more different packages from server side. Client side will surely have jQuery, Bootstrap, grunt, any Javascript frameworks like AngularJS, Backbone etc, images, style files. Client side package management in open source community has two great names “Bower” and “NPM”. They are part of “Dependencies”.

Server side packages save space in ASP.NET MVC 6

We have being using NuGet package manager to add reference to assemblies, library, framework or any third party packages. They would have being downloaded from NuGet which creates “Packages” folder in project structure. 30 sample ASP.NET MVC 5 applications, all of them use NuGet packages to reference dependencies each costly approx 70 MB disk space, so we end up nearly using 2GB disk space for storing packages even though they all are same.

Some SMART developers know this issue, they have some work around of their own. ASP.NET 5 with DNX came up with storing all the packages related to its development in Users folder and while creating ASP.NET 5 applications, Visual Studio will reference them from Users folder. Now even if you have 100 sample ASP.NET 5 applications, they all are referencing from DNX(4.5.1/ Core 5.0) in Users folder which is near to 400 MB as of now.

Inbuilt Dependency Injection (DI) support for ASP.NET MVC 6

Dependency Injection (DI) achieves loosely coupled, more testable code, its very important because its kind of coding standard. In ASP.NET MVC 5/4 or classic ASPX based applications, we use to have separate DI containers used like Unity, AutoFac, StructureMap etc,. We had to build up our project to use DI, its additional effort.

Now in ASP.NET 5 or MVC 6 applications, dependency injection is inbuilt i.e. no setup headache for DI. Just create some services and get ready to use DI. Infact sample MVC 6 application has DI inbuilt in it, lets open “StartUp.cs” and look for “ConfigureServices(IServiceCollection services)” method. Its main purpose is configuration of services like EF, Authentication, adding MVC and hand written custom services like IEmailServer and ISmsSender.

ASP.NET MVC 6 doesn’t need IIS for hosting

Don’t get surprised, the goal of ASP.NET 5 is to be cross platform using .NET core framework. With this in mind Microsoft decided to host ASP.NET 5 applications not only on IIS but they can be self hosted or use kestrel web server on linux. Things are quite in development stages apart from IIS hosting but soon we can host them on any OS. Check hosting.ini file of sample ASP.NET MVC 6 application, “Microsoft.AspNet.Server.WebListener” as acts self hosting service.

User Secrets of ASP.NET 5

Many times we keep sensitive data during our development work inside project tree, often we mistaken share these secrets with other through sharing of code, accidentally adding it TFS (source control). Once in while we might have experienced this.

ASP.NET 5 based applications have now concept of User Secrets; if we look at “project.json” file, we see that “userSecretsId” is present and Secret Manager tool uses this id to generate user secrets. The Secret Manager tool provides a more general mechanism to store sensitive data for development work outside of your project tree. The Secret Manager tool does not encrypt the stored secrets and should not be treated as a trusted store. It is for development purposes only.

In Memory execution of code files leads to EMPTY BIN folder

This is most important feature shipped with ASP.NET 5 (MVC6) applications. We always had to stop execution so that we can edit code files and run again to reflect changes. ASP.NET 5 has introduced in memory execution of code so that we don’t stop execution, make changes, build it and run application to see changes.

Without code being written, we will see how in memory code execution leads to EMPTY BIN folder. Open sample ASP.NET MVC 6 application(if not open), build it and run it. We can see start up screen in our browser. If we go bin folder of this application, its EMPTY. Traditionally we would see DLLs, reference files & DLLS and other files.

Application start up page can be seen in browser, no compiled code in artifacts folder but still everything works fine. This is magic of IN MEMORY execution of ASP.NET 5 applications. If we want get compiled code then check option “Produce outputs on build” and compile again to see.