First look at the project

Open VS2015, create a Web project, select ASP.NET Web Application, and select the ASP.NET 5 Website template in the pop-up window to create a project, as shown below:

We can see that the Web Forms\MVC\Web API checkboxes cannot be selected at this time. This is because a lot of changes have been made in ASP.NET 5, removing the Web Forms feature and combining the MVC, Web API, and Web Pages features together, so these checkboxes are naturally not needed. In addition, since this is a CTP version, the creation of unit test projects is not yet supported.

The solution directory structure and actual folder structure of the newly created project in VS are as follows:

Note: The above picture is a screenshot of the VS preview version. In the new RC version, the default client build tool has become gulp (that is, the configuration file is gulpfile.js) instead of the original grunt.

The difference between the two figures is very large. Let's analyze these differences one by one.
Differences in project structure

From the diagram, we can see that in the root directory, not only has the project file changed from csproj to xproj, but there are also many fewer previous files (such as web.config), but there are also many more different files and folders. Let's first list these different files and folders, and then explain these contents one by one.
File/Folder Function Description
config.json is the configuration file of the program, similar to web.config.
project.json is the main configuration of the project, mainly responsible for assemblies, project deployment, etc. Some functions are similar to the previous package.config.
package.json is the configuration file of npm, which is a package manager based on Nodejs.
bower.json is the configuration file of Bower manager. Bower is a package manager specifically used to manage front-end projects.
gulpfile.js is the configuration file of gulp. Gulp is a Javascript task manager based on Nodejs. In ASP.NET5, it is mainly used to manage the content in NPM and Bower.
Stratup.cs program startup entry, similar to Global.asax.
Project_Readme.html Project description file, useless.
wwwroot is the storage directory for static resource files (such as css, pictures, js).
Dependencies Dependency management packages for Bower and NPM.
References Assembly references, similar to the previous ones, but now there are versions (such as ASP.NET 5.0 and ASP.NET Core 5.0).
project.json

project.json is the core configuration file of the project. The example is as follows:

 {
 "webroot" : "wwwroot" ,
 "version" : "1.0.0-*" ,
 "dependencies" : {
 "Microsoft.AspNet.Diagnostics" : "1.0.0-beta4" ,
 "Microsoft.AspNet.Mvc" : "6.0.0-beta4" ,
 "Microsoft.AspNet.Mvc.TagHelpers" : "6.0.0-beta4" ,
 "Microsoft.AspNet.Server.IIS" : "1.0.0-beta4" ,
 "Microsoft.AspNet.Server.WebListener" : "1.0.0-beta4" ,
 "Microsoft.AspNet.StaticFiles" : "1.0.0-beta4" ,
 "Microsoft.AspNet.Tooling.Razor" : "1.0.0-beta4" ,
 "Microsoft.Framework.ConfigurationModel.Json" : "1.0.0-beta4" ,
 "Microsoft.Framework.CodeGenerators.Mvc" : "1.0.0-beta4" ,
 "Microsoft.Framework.Logging" : "1.0.0-beta4" ,
 "Microsoft.Framework.Logging.Console" : "1.0.0-beta4" ,
 "Microsoft.VisualStudio.Web.BrowserLink.Loader" : "14.0.0-beta4" ,
 "Microsoft.Framework.ConfigurationModel.UserSecrets" : "1.0.0-beta4"  
 },
 "commands" : {
 "web" : "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5000" ,
 "gen" : "Microsoft.Framework.CodeGeneration"  
 },
 "frameworks" : {
 "dnx451" : { },
 "dnxcore50" : { }
 },
 "exclude" : [
 "wwwroot" ,
 "node_modules" ,
 "bower_components"  
 ],
 "publishExclude" : [
 "node_modules" ,
 "bower_components" ,
 "**.xproj" ,
 "**.user" ,
 "**.vspscc"  
 ],
 "scripts" : {
 "postrestore" : [ "npm install" , "bower install" ],
 "prepare" : [ "gulp copy" ]
 }
 }

Since the file contains many detailed parameters, please refer to http://go.microsoft.com/fwlink/?LinkID=517074 for details. Here we mainly explain the following three types of content.
webroot

webroot specifies the static file storage address of the web project. It is currently used to specify the correct location for internal publishing in the directory when publishing (details can be found in the deployment and publishing section). Note that the wwwroot directory with a globe icon in the BookStore solution is a real folder path. We can modify it, for example, change it to wwwroot1, then the corresponding webroot value should also be changed to wwwroot1, because the code in gulpfile.js uses the directory through project.webroot, so that the front-end libraries managed by bower can be copied to the correct directory.
Assembly Management

In the References node of the solution, we see two categories: DNX 4.5.1 and DNX Core 5.0. DNX Core 5.0 is what we call the cloud-optimized version (i.e. a cross-platform version that can be deployed on other operating systems), while DNX 4.5.1 is the same full-featured version as the previous version. The assemblies of these two versions are managed through the dependencies node.

In the first-level dependencies node, the common assembly references and versions of the project are mainly defined, and different versions of assemblies are maintained in the dependencies nodes under each version of framworks, for example:

 "frameworks" : {
 "dnx451" : {
 "dependencies" : { "log4net" : "2.0.3" } /* Only introduce the log4net assembly in the full-featured version*/   
 
 },
 "dnxcore50" : { }
 }

When maintaining the above two types of assemblies, there are intelligent prompts (including assembly name and version number). After defining the assembly you want to use and saving it, the system will automatically download the required assembly from Nuget. You can also update all assembly references by right-clicking References and selecting Restore Packages. At the same time, you can still manage these assemblies through Nuget by right-clicking References.
Script Events

The new version of VS2015 allows us to customize some Nodejs-based custom events to execute before, after, and during the build of the solution; before, after downloading the assembly; before, after updating the assembly. The event is defined in the scripts node in project.json, as shown below:

 "scripts" : {
 "postrestore" : [ "npm install" ], // Execute the npm install event before updating all assemblies  
 "prepare" : [ "gulp copy" ]
 // Before opening the solution, execute the gulp task and call bower's install method.  
 }

The specific event names are as follows:

package.json is the configuration file of the NPM manager. Since Nodejs is deeply integrated by default in VS2015, and NPM is the default package manager of Nodejs, all packages based on Nodejs must be configured here. The default configuration of this configuration file is as follows:

 {
 "name" : "ASP.NET" ,
 "version" : "0.0.0" ,
 "devDependencies" : {
 "gulp" : "3.8.11" , //gulp task manager  
 "rimraf" : "2.2.8"   // Nodejs package that recursively deletes files  
 }
 }

The rimraf in the above code is a nodejs package that recursively deletes files. We can also reference other plug-ins. Just like managing assemblies in the project.json file, we can manage various packages of front-end programs in the package.json file, such as jquery, bootstrap, etc. For example, if we want to install an express package, we only need to add an express string key in the json file and select the version. The system will automatically download the NPM package and display it under the Dependencies->NPM node of the solution.

Note: Installed packages cannot be removed automatically (that is, they cannot be removed by configuration in JSON). You need to right-click the package and uninstall it manually.

bower.json

All front-end packages are configured in the bower.json file, such as jquery, bootstrap, angular, etc. that you need. Their management method is the same as the assemblies in project.json and the npm packages in package.json, which are all achieved by declaring the package name and version under the dependencies node.

We can declare an angular package here. After saving, you can see that the angular has been automatically downloaded under the solution Dependencie->Bower node. Compile the project, and you can see the angular folder and corresponding files in wwroot/lib.

There is also an exportsOverride node in bower.json, which is very important. It extends the original bower front-end file copy mechanism. By default, bower will only copy the files defined by the main node. But sometimes we may need to copy more than these files, so the grunt-bower-task plug-in extends this function and defines this exportsOverride node. Its usage rules are as follows:

If the Bower package defines a main file node, copy it to wwwroot/lib.
If the main node defined by the Bower package is empty, the entire package directory is copied to wwwroot/lib.
If the exportsOverride node is defined, only the files specified by the node will be copied to wwwroot/lib.

Note that the key/value defined in the exportsOverride node, where the key represents the subdirectory under the package name corresponding to the file copy target (i.e. wwwroot/lib), and the value represents the source file directory or file. For example:

 "bootstrap" : {
 "js" : "dist/js/*.*" , //Copy all files under dist/js/ to the wwwroot/lib/bootstrap/js directory  
 "css" : "dist/css/*.*" ,
 "fonts" : "dist/fonts/*.*"  
 },
 "jquery" : {
 "" : "jquery.{js,min.js,min.map}"   // Copy jquery.js, jquery.min.js, and jquery.min.map files to the wwwroot/lib/jquery directory  
 },

Note: Similar to NPM, packages configured in bower.json cannot be removed automatically. You need to uninstall the package from Bower and remove the related files from wwwroot/lib.

gulpfile.js

gulpfile.js is the configuration file of the gulp task manager. By default, this configuration file will clear all files in the wwwroot/lib directory (clean task) and then copy them from the bower_components directory (copy task).

The modification of this file configuration will affect the display of Task Runner Explorer in VS, as shown in the following figure:

Taking the default configuration as an example, the configuration file registers two tasks in the Task directory, namely clean and copy. By default, the clean task is re-executed after the VS solution is cleared and compiled. However, we can also bind the task to any execution time point. We can right-click the task -> Bind -> Before Build, and then click the Refresh button on the left side of the panel. At this time, the binding content will be synchronously saved in the first line of gulpfile.js. The code is as follows:

 /// < binding   BeforeBuild = 'copy'   Clean = 'clean'   />  

At this point, delete all the files in the wwwroot/lib directory, and then recompile the BookStore project. All the required files will be automatically generated in the wwwroot/lib directory, that is, all the packages defined in Bower.json will be copied to this directory according to the configuration requirements.
clean task

The main function of the clean task is to delete all front-end files in the lib directory before compiling or cleaning the solution, so that new files can be copied again. The specific analysis is as follows:

 var gulp = require( "gulp" ), // reference gulp  
 rimraf = require( "rimraf" ), // reference rimraf  
 fs = require( "fs" ); //reference the file system   
 
 eval( "var project = " + fs.readFileSync( "./project.json" )); //Read the project.json configuration file   
 
 var paths = {
 bower: "./bower_components/" ,
 lib: "./" + project.webroot + "/lib/"  
 }; 
 
 gulp.task( "clean" , function (cb) { //Register clean task  
 rimraf(paths.lib, cb); // Recursively delete all files in the lib directory  
 });

copy task

The copy task is very simple. It copies the qualified files in the bower_components directory to the lib directory. The analysis is as follows:

 gulp.task( "copy" , [ "clean" ], function () { // Register the copy task  
 var bower = { // Directory correspondence  
 "bootstrap" : "bootstrap/dist/**/*.{js,map,css,ttf,svg,woff,eot}" ,
 "bootstrap-touch-carousel" : "bootstrap-touch-carousel/dist/**/*.{js,css}" ,
 "hammer.js" : "hammer.js/hammer*.{js,map}" ,
 "jquery" : "jquery/jquery*.{js,map}" ,
 "jquery-validation" : "jquery-validation/jquery.validate.js" ,
 "jquery-validation-unobtrusive" : "jquery-validation-unobtrusive/jquery.validate.unobtrusive.js"  
 } 
 
 for (var destinationDir in bower) {
 gulp.src(paths.bower + bower[destinationDir]) // Read the source directory  
 .pipe(gulp.dest(paths.lib + destinationDir)); //Copy to the destination folder  
 }
 });

Grunt Tasks

In VS2015, although the Gulp build tool is supported by default, the Grunt build tool is also supported. The usage is similar to Gulp. To use Grunt, you also need to reference similar dependency packages. The example is as follows:

 {
 "version" : "0.0.0" ,
 "name" : "" ,
 "devDependencies" : {
 "grunt" : "0.4.5" , //grunt task manager  
 "grunt-bower-task" : "0.4.0"   // Bower management plugin based on grunt  
 }
 }

The grunt-bower-task in the above code is a grunt-based bower management plug-in, which is used to automatically execute bower's install command to install Bower packages.

Note: Installed packages cannot be removed automatically (that is, they cannot be removed by configuration in JSON). You need to right-click the package and uninstall it manually.

gruntfile.js is the configuration file of the grunt task manager. To use grunt, you need to create a gruntfile.js file. By default, this configuration file only configures the task execution of the grunt-bower-task plug-in. The plug-in will read the bower.json configuration information and install the relevant packages to the specified directory through the bower:install command (the default is the wwwroot/lib directory set by targetDir).

The modification of this file configuration will affect the display of Task Runner Explorer in VS, as shown in the following figure:

Take the default configuration as an example. The configuration file registers a task named default, which is displayed in the panel (Alias ​​Tasks list). This task is also the default task name of Grunt, but it does not define when the task is executed. So at this time we can bind an execution time point to the task. We can right-click the task -> Bind -> Before Build, and then click the Refresh button on the left side of the panel. At this time, the binding content will be synchronously saved in the first line of gruntfile.js. The code is as follows:

 /// <binding BeforeBuild='default' />  

At this point, delete all the files in the wwwroot/lib directory, and then recompile the BookStore project, which will automatically generate all the required files in the wwwroot/lib directory, that is, copy the various packages defined in Bower.json to this directory according to the configuration requirements. The tasks in Tasks are analyzed from the packages loaded in grunt.loadNpmTasks, such as bower.
Let's practice another example. Suppose we want to compress the site.css file in the wwwroot/css/ directory (compress it into site.min.css) before compiling. We can install it as follows:

First, define a grunt plugin that can compress CSS code in package.json:

 {
 "version" : "0.0.0" ,
 "name" : "" ,
 "devDependencies" : {
 "grunt" : "0.4.5" ,
 "grunt-bower-task" : "0.4.0" ,
 "grunt-contrib-cssmin" : "0.12.2"   /*New plugin*/  
 }
 }

Then under the bower peer node under grunt.initConfig, add the following content:

 /*Compress CSS*/
 cssmin: {
 target: {
 options:
 sourceMap: true,
 },
 files: {
 /*Output file path: original file path*/
 'wwwroot/css/site.min.css': 'wwwroot/css/site.css'
 }
 }
 }

***Register this plug-in again, the code is as follows:

 grunt.loadNpmTasks('grunt-contrib-cssmin'); /*Compress CSS*/

In this way, you can see the cssmin task in the Task Runner Explorer panel and run it. Of course, you can also add this task and the default task to execute before the compilation build. The code is as follows:

 /// < binding   BeforeBuild = 'default, cssmin'   />  

In addition, some examples are given, one is for js compression and the other is for less compilation. The code is as follows:

 /*package.json*/  
 "grunt-contrib-uglify" : "0.9.1" ,
 "grunt-contrib-less" : "1.0.1"   
 
 /*gruntfile.js*/  
 /*Compress js*/  
 uglify:
 target: {
 options:
 sourceMap: true ,
 },
 files: {
 'wwwroot/Scripts/site.min.js' : 'wwwroot/Scripts/site.js'  
 }
 }
 },
 /*compile less*/  
 less: {
 //Development version (no compression)  
 development:
 options:
 sourceMap: true  
 },
 files: {
 'wwwroot/Styles/site.css' : 'wwwroot/Lesses/site.less'  
 }
 },
 //Production version (compressed)  
 production:
 options:
 compress: true  
 },
 files: {
 'wwwroot/Styles/site.min.css' : 'wwwroot/Lesses/site.less'  
 }
 }
 }
 /*...*/  
 grunt.loadNpmTasks( 'grunt-contrib-uglify' ); /*Compress js*/  
 grunt.loadNpmTasks( 'grunt-contrib-less' ); /*compile less*/  

Recommendation: Do not bind the same task to multiple periods.
Recommended: grunt also has a plug-in for monitoring file modifications, such as compatible CSS file modifications. Once modified, the CSS compression command is called. For details, please refer to the grunt-contrib-watch plug-in.

config.json

config.json is the previous web.config, but it is not as powerful as web.config in that it has various types of configurations. The configurations of various functions are transferred to the Startup.cs file in the form of code; another part of the information configuration content is placed in the config.json file and saved in json format.

Note that the information in this file is not automatically loaded by default, but you need to load the configuration information manually. The code is as follows:

 //In the constructor of the Startup.cs class  
 Configuration = new Configuration()
 .AddJsonFile( "config.json" )
 .AddEnvironmentVariables();

The configuration file is loaded through the Configuration instance and saved in the Configuration property so that it can be used elsewhere. The key value when using it is defined according to the hierarchy, with the following default content as an example:

 {
 "AppSettings" : {
 "SiteTitle" : "WebDemo01"  
 }
 }

To get the connection string, you need to use the following key value:

 var connString = Configuration.Get( "AppSettings:SiteTitle" );

It is not as convenient to use as web.config, but this is the only way to be compatible with other operating systems.

Note: In ASP.NET 5, configuration information not only supports json format, but also supports ini, xml and other formats. For details, please refer to the subsequent configuration information management chapter.

Startup.cs

Startup.cs is the startup entry point of the entire program, similar to Global.asax. Like the Global.asax file, it plays the role of global configuration information. Let's analyze several important functions of this file.

First, initialize the basic configuration information in the constructor (for detailed configuration information, please refer to the Configuration Information Management section). Note that the initialized configuration information here is bound to a Configuration property so that the other two methods can use it later. If you want to use it in other classes, you need to save the instance somewhere else (such as a static variable).

The ConfigureServices method is the core of dependency injection. In the method's incoming parameter services, the type definition defined in the default dependency injection is first saved. Then we can continue to register the type definition of dependency injection in this method. For details about dependency injection, you can read the Dependency Injection chapter.

At the same time, if some important functions need to be enabled, they also need to be enabled here. For example, to add the Mvc module, you need to use the following call statement:

services.AddMvc();

The reason is that, in the new version of ASP.NET 5, except for the most basic modules, most modules are pure componentized, which is called Middleware. When using a component, you need to add the module before you can use it. For example, if you add the EF module, you need to call

services.AddEntityFramework() method.

The other Configure method, as the name implies, is where various Middleware components are configured. Generally speaking, the method for configuring a module is to call methods like app.UseXXX(). For example, if you use a static file processing flow, you can call the following statement:

 app.UseStaticFiles();

If you want to use the Mvc function, you need to use the app.UseMvc method. When calling these methods, you can configure and pass in the response parameters.

Note that the services.AddXXX() type methods used in ConfigureServices and the app.UseXXX() type methods used in the Configure method are extension methods. The AddXXX() method is extended on the IServiceCollection interface, while the UseXXX() method is extended on the IApplicationBuilder interface.

Regarding the dependency injection mentioned in this file, and the three types of parameters in the Configure method: IApplicationBuilder, IHostingEnvironment, and ILoggerFactory; we will explain them in detail in subsequent chapters.

other

By checking, you can find that the web.config in the Views directory has also been removed. In the RC version, to unify the reference namespace, you need to use the ViewStart.cshtml or GlobalImport.cshtml file, which we will talk about in the subsequent chapters.

We don't need to make any changes, just press F5 to run the project. Since IIS Express is used by default, the homepage of the new website will be opened automatically. If it is not IIS Express, please read the subsequent compilation and deployment chapters.