Interpretation of ASP.net 5 & MVC6 Series (3): Project Release and Deployment _ self-study process

In this chapter we will explain the ASP.NET5 Project release deployment, and the example project takes the bookstore project we created in the previous chapter as an example.

Settings prior to publishing

Since the new ASP.NET5 supports the release and deployment of a multiple-version DNX runtime environment, we need to set the target DNX (that is, the previous kre) before deployment.

Step: Right-click the bookstore Item-> Properties->application tab, select Dnx version, in this case, select dnx-coreclr-win-x64.1.0.0-beta4 .

At the node of the project.json file, commands we can see that the system is configured by default with 3 debugging commands, respectively, as follows:

Command	Description
Web	Starts the Weblistener service, which lets the Web program run out of IIS, and the default address is http://localhost:5000.
Gen	Use this command to generate MVC-related code, such as controller, that is not currently available.
Ef	The Entity Framework Migration command is used to migrate data, and in this case we do not have a user.

Theoretically, when we run the F5, we should start the Web command, but in VS2015, the default operating environment is still IIS Express, so F5 debugging will start IIS Express by default.

Gen Reference: http://www.jb51.net/article/87244.htm
Note: Web mode and IIS Express mode program run ports are not the same.

We first F5 debugging run, start the IIS Express, open the page, all normal. Re-select the default emulator environment for the web, then F5 run, this time found a pop-up command line window, and prompted the following text:

[INFORMATION:Microsoft.NET.Http.Server.WebListener] Start
[INFORMATION:Microsoft.NET.Http.Server.WebListener] listening on prefix:http://localhost:5000/
Started

The code does not have an error, but does not open a browser window, we manually open a browser to access the above Web site, you can see the sample program interface, at this point, the bookstore has successfully run on port 5000. In fact, the browser automatically open in this mode is turned off by default, you can turn on the automatic function by the following means:

Step: Right-Bookstore The project-> Properties->debug tab, check the launch Brower checkbox, and enter the above URL in the input box (this will be in the project's properties directory to generate a Debugsettings.json file to save the above information).

F5 run again to see the Automatically open browser interface.

Application parameters
In the Debug tab, we also see an application parameter ( Application Arguments ) input box, which can be passed in multiple parameters, which can be Startup.cs Configuration AddCommandLine collected and utilized in the method.

Environment variables
Similarly, there is an environment variable () input box at the bottom of the Debug tab Environment Variables that allows us to customize the values of some environment variables (key/value) while debugging, and then Configuration AddEnvironmentVariables collect and exploit them.

Refer to the Configuration Information Management Section for the specific use of the above parameters and environment variables.

Publishing Process Analysis

In the previous MVC program, we typically publish the program by right-clicking the project, choosing to publish (Publish), and this time we'll look at that way as well.

First, right-click-> publish->profile (select File System)-> Select D:\BookStore -> Select Release/coreclr -> Next, and finally hit publish. In the output panel, we saw an error with the error message as follows:

By looking at the output information, you can see that the compilation was successful, but there was an error in the copy, which could be a PowerShell issue, so go back to the above steps, and under the Settings tab, the Publish script will be canceled (Publish Scripts), use the PowerShell script to publish the check box. republished, succeeded.

Opens the Publish directory D:\BookStore, and discovers the following directories and files are generated:

directory or file	Description
AppRoot	Application directory
Wwwroot	Static file directory
Gen	Linux shell command file
Gen.cmd	cmd command file
Web	Linux shell command file
Web.cmd	cmd command file

See the extension of the cmd file, we can guess that these commands are used to execute the relevant commands, such as web.cmd may be used to start the program, rather than the cmd extension file, we suspect that it may be used for Linux/mac run the command.

Let's try, click on the web.cmd file, the file will be displayed after the information and we are in the Debug program pop-up information like, by accessing the URL in the hint, we can verify that the application is working properly. This pattern is what we call the Self-host operating mode.

Try again if IIS is able to run the program, point the IIS site to the wwwroot directory, and open the URL, which can also be accessed normally. Open wwwroot folder for viewing, static files readily available, but found that the bin directory does not have our project DLL ( BookStore.dll ), but one more AspNet.Loader.dll , and the root directory has a more than one web.config file, the contents are as follows:

<?xml version= "1.0" encoding= "Utf-8"?>
<configuration>
 <appSettings>
 <add key= " Bootstrapper-version "value=" 1.0.0-beta4 "/> <add key=" Runtime-path "value="
 . \approot\packages "/> <add key=" dnx-version "value=" 1.0.0-beta4 "/> <add key=" dnx-clr "value="
 CoreCLR "/>
 <add key=" Dnx-app-base "value=". \approot\src\bookstore "/>
 </appSettings>
</configuration>

By querying for relevant information (access details), you know that the AspNet.Loader.dll file is just a bridging file, used to receive requests forwarded by IIS and then forwarded to dnx run, where the web.config DNX and the project information configuration file are AspNet.Loader.dll The configuration information that is required when the request is forwarded.

The configuration file lets you see the dnx type, version number, path of the assembly, and the path of the app. Open the approot\src\BookStore directory, we found that there are actually CS source code, although there is a bin directory, but there is no DLL file. and approot\packages under the folder, there are 90 assembly folders (nearly 30M files).

By querying the website for information (this part, as we explained in the next section), the current running environment of the program is DNX also replicated to the approot\packages\dnx-coreclr-win-x64.1.0.0-beta4 directory, and all the assemblies that the project relies on (including the system's beginning) are copied to the packages directory. The goal is to do a real cross-platform operation, that is, to copy these files to a Linux system, and to run the program as long as there is a corresponding version of Kre (the DNX in this case is a version of Windows).

And the bin directory does not have DLL files, it is the use of Microsoft's latest dynamic compiler technology, that is, in the process of running, the automatic compilation of CS files, and once modified these CS files, the system will automatically compile again. (It feels a bit like a scripting language such as PHP). Although dynamic compilation is efficient, but there is still no compiled DLL efficient, Microsoft also provides an option for developers to generate DLL files when debugging. The specific steps are as follows:

右键BookStore->属性->Build选项卡，勾选编译时生成输出（Produce outputs on build）复选框。

Recompile the program, found in the BookStore\artifacts\bin\BookStore\Debug directory under the 2 DNX version of the folder are generated BookStore.dll files, but also incidentally NuGet spec file.

If you want to build the DLL file when you publish it, you need to modify it in the Publish (Publish) setting, as follows:

右键BookStore->发布（Publish）->Settings选项卡->File Publish Options->勾选Precompile during publishing复选框。

This allows you to generate the DLL files for the response, but the DLL files are still not in the Wwwroot/bin directory, but in the directory where approot\packages\BookStore\1.0.0 there are 2 folders, respectively, lib and the root associated NuGet spec files, in the Lib directory, Generated is a different version of the DLL file, and root is similar to the previous Web root directory, because in addition to the view file in the directory, as well as the previous structure, the bin directory is preserved, and in the Bin directory under the Release folder, the DNX There is also a copy of the DLL file for different DNX versions.

Tip: In the above selection, another delete all existing file prior to publish can also be checked so that all files from the previously released version will be emptied at the time of publication.

At this point, we use Web.cmd file or IIS mode to verify the published file, verified, can run correctly. A careful comparison of two different published files found that, in addition to the DLL file, the Web.config file's application path changed, that is, from the original:

<add key= "Kre-app-base" value= ". \approot\src\bookstore "/>

becomes the following version:

<add key= "Kre-app-base" value= ". \approot\packages\bookstore\1.0.0\root "/>

The contents of the Web.cmd file are also from the following:

@ "%~dp0approot\packages\dnx-coreclr-win-x64.1.0.0-beta4\bin\dnx.exe"--appbase "%~dp0approot\src\bookstore" Microsoft.Framework.ApplicationHost Web%*

becomes the following:

@ "%~dp0approot\packages\kre-coreclr-win-x64.1.0.0-beta4\bin\dnx.exe"--appbase "%~dp0approot\packages\bookstore\ 1.0.0\root "Microsoft.Framework.ApplicationHost Web%*

The above changes, we are understandable, will be the SRC source code dynamic compilation run mode modified to precompiled DLL assembly mode. So, here we can see that in the source code dynamic compilation mode, the folder structure after its release is as follows:

Source code dynamic compilation mode
wwwroot/bin/microsoft.aspnet.loader.iis.dll
wwwroot/contents/site.css
wwwroot/contents/ .......................................
........................................................
Wwwroot/scripts/jquery.js
wwwroot/scripts/....... ....... ...... ..... ..... ..... ....
. ........................................................
........................................................
Approot/src/bootstore/project.json
approot/src/bootstore/.......... ....... ..... .....
Approot/src/bootstore.data/project.json
approot/src/bootstore.data/.......... ........ .....
.. Approot/src/bootstore.bussiness/project.json approot/src/bootstore.bussiness/........ .......... ...
approot/packages/elmah/{version}/...
............ ........................................................

The publishing folder structure in DLL precompilation mode is as follows:

DLL pre-compilation mode
wwwroot/bin/microsoft.aspnet.loader.iis.dll
wwwroot/contents/site.css
wwwroot/contents/ .......................................
........................................................
Wwwroot/scripts/jquery.js
wwwroot/scripts/....... ....... ...... ..... ..... ..... ....
. ........................................................
........................................................
approot/packages/bootstore/{version}/............
approot/packages/bootstore.data/{version}/........
approot/packages/bootstore.bussiness/{version}/..... approot/packages/elmah/{version}/...............

Different IIS and Web.cmd modes

Although we do not understand the principle of dnx content, but there is a bit of content, we should remember that in both modes, the mode of access to static files may not be the same. The reason is that although the root directory of IIS mode is where the static files are stored, the Web.cmd file is first started with a approot\src\BookStore directory or approot\packages\BookStore\1.0.0\root directory, there are no static files in two directories, because the static file is in the wwwroot directory, we guess, in this mode, There will certainly be a mechanism to map these static files by looking up files to find that the value of the key in the file in the approot\src\BookStore directory is project.json changed from the default in the webroot solution, which means that wwwroot "../../../wwwroot" Kre is mapping the static file, It should be based on this relative directory to find these files.

Similarly, the value of the key in the file in the approot\packages\BookStore\1.0.0\root directory is project.json webroot also wwwroot changed from "../../../../../wwwroot" (because project.json the level of the original file is deep).

Since IIS is running by forwarding the request to DNX, is the AspNet.Loader.dll request for static files in IIS mode handled by IIS or Kre? Let's verify that the verification steps are as follows:

Create a wwwroot2 folder and wwwroot sibling, and wwwrooot cut the static files in the directory to the wwwroot2 directory. The changes in the values in the Project.json file in the root directory will need to be modified in the case of project.json precompiled mode webroot wwwroot wwwroot2 . Continue running the site in IIS mode

Results found that static files can not be accessed (CSS, JS, images are invalid), but we run through the web.cmd, these static files are also accessible. As a result, in IIS mode, static files go through the pipeline of the IIS pipeline rather than the DNX relationship pipeline.

Different Project.json files in two publishing modes

Dynamic compilation mode and precompiled DLL mode of the two modes of automatic publishing program, generated Project.json files have some changes, the specific changes are as follows.

Dynamic compilation mode
Basically the same as the Project.json file in the solution, the only difference is the modification of the Webroot relative path.

Pre-compiling DLL mode
Many of the previously referenced assemblies were removed from the dependencies node and replaced by bookstore assembly references, as follows:

"Dependencies": {
 "bookstore": "1.0.0"
},

In addition, there are more than the following two node values (specific features are temporarily ambiguous):

"EntryPoint": "Bookstore",
"loadable": false

Guess that these differences may be due to the need to refer to these removed assemblies for compilation in dynamic compilation mode, while precompiled DLL mode has been compiled so that the assemblies are no longer needed, and the root directory only needs to refer to the bookstore assembly. The bookstore assembly's reliance on these assemblies is automatically parsed and downloaded in the nupkg file of the DLL assembly (this is to be verified).

These are some of the new ASP.NET5 projects in the release process and related technology, from here you can see that ASP.NET5 is completely modular, IIS is no longer the only container running the MVC program, any compatible DNX running container can run the MVC program, the program release package is divided into AppRoot and Wwwroo T two parts, separate the application set (or source code) and static files, so as to achieve better separation. In the next chapter, we'll discuss how the ASP.net 5 works.

Note: There is no way to copy the source of the form of debugging, but also have no way to point IIS to the source code for debugging, which will change the development habits of developers.