Interpretation of ASP. NET 5 & MVC6 series (3): Project release and deployment, and interpretation of ASP. NET

Interpretation of ASP. NET 5 & MVC6 series (3): Project release and deployment, and interpretation of ASP. NET

This chapter describes ASP. NET5 project release and deployment. The example project uses the BookStore project created in the previous chapter as an example.

Pre-release settings

The new ASP. NET5 version supports the release and deployment of multiple DNX runtime environments. Therefore, before deployment, we need to set the target DNX (the previous KRE ).

Step: Right-click the BookStore project> Properties> Application tab and select the version of DNX. In this example, selectdnx-coreclr-win-x64.1.0.0-beta4.

Inproject.jsonFilecommandsNode, we can see that the system configures three Debugging commands by default, respectively:

Command	Description
Web	Start the WebListener service, which can run web programs out of IIS. The default address is http: // localhost: 5000.
Gen	Use this command to generate MVC-related code, such as Controller, which is not yet used.
Ef	Entity Framework migration command, used for data migration. In this example, we do not have the user.

In theory, we should start the web command when F5 runs, but in VS2015, the default runtime environment is still IIS Express, so during F5 debugging, IIS Express is started by default.

Gen Reference: http://www.bkjia.com/article/87244.htm
Note: The web mode and IIS Express mode have different program running ports.

Let's debug and run F5, start IIS Express, and open the page. Everything is normal. Re-select the web as the default simulator environment and run it with F5. a command line window is displayed, prompting the following text:

[INFORMATION: Microsoft.NET.Http.Server.WebListener] Start
[INFORMATION: Microsoft.NET.Http.Server.WebListener] Listening on prefix: http: // localhost: 5000 /
Started
There is no error in the code, but the browser window is not opened. We manually open a browser to access the above URL, and you can see the interface of the sample program. At this time, the BookStore has successfully run on port 5000. In fact, the automatic opening function of the browser in this mode is turned off by default, and the automatic opening function can be turned on as follows:

Steps: Right-click the BookStore project-> Properties-> Debug tab, check the Launch Brower check box, and enter the above URL in the input box (at this time, a debugSettings.json file will be generated in the project's Properties directory to save Above information).

Run F5 again to see the browser interface that opens automatically.

Application parameters
In the Debug tab, we also see an application parameter (Application Arguments) input box, the input box can pass in a variety of parameters, these parameters can be collected and used in Startup.cs through the AddCommandLine method of Configuration .

Environment variables
Similarly, there is an environment variable (Environment Variables) input box at the bottom of the Debug tab, which allows us to customize the value of some environment variables (key / value) during debugging, and then collect through the AddEnvironmentVariables method of Configuration And use.

For specific usage of the above parameters and environment variables, please refer to the configuration information management chapter.

Release process analysis

In the previous MVC program, we generally publish the program by right-clicking the project and selecting Publish. This time we will also take a look at this method.

First, right click-> publish-> Profile (select File System)-> select D: \ BookStore-> select Release / coreclr-> next, and finally click publish. In the Output panel, we see an error, the error message is as follows:

Connecting to D: \ Documents \ Visual Studio 2015 \ Projects \ BookStore \ BookStore \ .. \ artifacts \ bin \ BookStore \ Release \ Publish ...
C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0 \ Web \ Microsoft.DNX.Publishing.targets (342,5): Error: Error: The rule "BackupRule" cannot be recognized.
C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0 \ Web \ Microsoft.DNX.Publishing.targets (342,5): Error: Error count: 1.

C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0 \ Web \ Microsoft.DNX.Publishing.targets (342,5): Error: An error occured during publish.
The command ["C: \ Program Files (x86) \ IIS \ Microsoft Web Deploy \ msdeploy.exe" -source: contentPath = 'C: \ Users \ Administrator \ AppData \ Local \ Temp \ PublishTemp \' -dest: contentPath = 'D: \ Documents \ Visual Studio 2015 \ Projects \ BookStore \ artifacts \ bin \ BookStore \ Release \ Publish' -verb: sync -enableRule: DoNotDeleteRule -retryAttempts: 2 -disablerule: BackupRule] exited with code [-1].
By looking at the output information, you can find that the compilation was successful, but there was an error when copying, which may be a problem with powershell, so return to the above steps. Under the Settings tab, the use of PowerShell scripts under Publish Scripts will be cancelled. Publish checkbox. Republished successfully.

Open the publishing directory D: \ BookStore and find that 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
Seeing the extension of the cmd file, we can guess that these commands are used to execute related commands. For example, web.cmd may be used to start the program; instead of the cmd extension file, we guess that it may be used for linux / mac Command to run.

Let's try it. Click the web.cmd file. The information displayed after the file is executed is the same as the information that we popped up during the Debug program. By accessing the URL in the prompt, we can verify that the application has run normally. This mode is what we call the Self-Host mode of operation.

Try again whether IIS can run the program, point the IIS site to the wwwroot directory, and open the URL, which can also be accessed normally. Open the wwwroot folder to view, the static files are all available, but found that there is no our project DLL (BookStore.dll) in the bin directory, but an additional AspNet.Loader.dll, and there is an additional web in the root directory .config file, the content is 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 related information (access details), I learned that the AspNet.Loader.dll file is just a bridge file, used to receive the request forwarded by IIS, and then forward it to dnx to run, here dnx and project in web.config The information configuration file is the configuration information required by AspNet.Loader.dll when forwarding the request.

Through the configuration file, we can see that the dnx type, version number, assembly path and app path are configured here. Open the approot \ src \ BookStore directory, we found that here are actually cs source code, although there is a bin directory, but there is no dll file. And under the approot \ packages folder, there are actually 90 assembly folders (almost 30M files).

According to the information on the website (this part, we will explain in the next section), the current running environment of the real program is DNX, which is also copied to approot \ packages \ dnx-coreclr-win-x64.1.0.0- In the beta4 directory, all the assemblies that the project depends on (including the beginning of System) are copied to the packages directory. The purpose is to achieve true cross-platform operation, that is to say, copy these files to the Linux system, as long as there is a corresponding version of KRE (DNX in this example is the Windows version), you can run the program normally.

But there is no dll file in the bin directory, it uses Microsoft's latest dynamic compilation technology, that is, the cs file is automatically compiled during operation, and once these cs files are modified, the system will automatically compile again. (It feels a bit like scripting languages like PHP). Although dynamic compilation is very efficient, it is still not as efficient as compiled dlls, so Microsoft also provides an option for developers to generate dll files when debugging. Specific steps are as follows:

Right-click BookStore-> Properties-> Build tab, and check the Produce outputs on build check box.

Recompile the program, and found that the two Bookstore \ artifacts \ bin \ BookStore \ Debug directories have generated the BookStore.dll file under the two DNX version folders, and also accompanied by Nuget's spec file.

If you want to generate a dll file when publishing, you need to modify it in the Publish settings. The steps are as follows:

Right-click BookStore-> Publish-> Settings tab-> File Publish Options-> check the Precompile during publishing check box.

In this way, the corresponding dll files can be generated, but these dll files are still not in the wwwroot / bin directory, but in the approot \ packages \ BookStore \ 1.0.0 directory. There are two folders in this directory, namely lib and root, and related Nuget spec files, in the lib directory, generate dll files of different dnx versions, and root is similar to the previous web root directory, because in this directory, in addition to view files, it also has The previous structure is the same, the bin directory is retained, and in the Release folder under the bin directory, there is also a copy of the dll file for different dnx versions.

Tip: In the above selection, another Delete all existing files prior to publish can also be checked, so that all files in the previously released version will be emptied when publishing.

At this time, we verify the published files through the web.cmd file or the IIS mode. After verification, they can all run normally. Then carefully compare the two different release files, and found that in addition to the dll file, the application path of the web.config file has also changed, that is, from the original:

<add key = "kre-app-base" value = ".. \ approot \ src \ BookStore" />
It became the following version:

<add key = "kre-app-base" value = ".. \ approot \ packages \ BookStore \ 1.0.0 \ root" />
The content of the web.cmd file is also as follows:

@ "% ~ dp0approot \ packages \ dnx-coreclr-win-x64.1.0.0-beta4 \ bin \ dnx.exe" --appbase "% ~ dp0approot \ src \ BookStore" Microsoft.Framework.ApplicationHost web% *
Became 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% *
We can understand the above changes, that is, the mode of dynamically compiling and running src source code is changed to the mode of pre-compiled dll assembly. Therefore, here we can see that in the source code dynamic compilation mode, the folder structure after its release is as follows:

// Dynamic source code 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 release 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} / .............................
Difference between IIS and web.cmd modes

Although we don't quite understand the principle of dnx content, but there is a little content, we have to remember that that in two modes, the access mode for static files may be different. The reason is because, although the root directory of the IIS mode is where static files are stored, the web.cmd file is started in advance in the approot \ src \ BookStore directory or approot \ packages \ BookStore \ 1.0.0 \ root directory, two directories There are no static files underneath, because the static files are in the wwwroot directory. We guess that in this mode, there will definitely be a mechanism to map these static files. It is found by finding the files in the approot \ src \ BookStore directory. The value of the webroot key in the project.json file of the project has changed from the default wwwroot in the solution to "../../../wwwroot", which means that when kre maps static files, it should be based on this Relative directory to find these files.

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

Since IIS is transferred through AspNet.Loader.dll and the request is transferred to DNX to run, then in IIS mode, is the static file request processed by IIS or KRE? Let's verify, the verification steps are as follows:

Create a wwwroot2 folder and the same level as wwwroot, and cut the static files in the wwwrooot directory to the wwwroot2 directory. Change the wwwroot in the webroot value in the project.json (if you are in pre-compilation mode, you need to modify the project.json in the root directory) file to wwwroot2. Continue to run the site in IIS mode

It turns out that static files cannot be accessed (CSS, JS, Images are all invalid), but when we run through web.cmd, these static files can be accessed again. It is learned that in IIS mode, the static file takes the pipeline pipeline of IIS, not the relation pipeline of DNX.

The project.json file is different in the two release modes

There are some changes in the project.json file after the automatic release of the two modes of dynamic compilation mode and pre-compiled dll mode. 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 relative path of the webroot.

Pre-compiled dll mode
Many of the original assemblies referenced were removed from the dependencies node and replaced by the BookStore assembly reference. Examples are as follows:

"dependencies": {
 "BookStore": "1.0.0"
},
In addition, the following two node values are added (the specific function is not yet clear):

"entryPoint": "BookStore",
"loadable": false
Guess, these differences may be because in dynamic compilation mode, these removed assemblies need to be referenced for compilation, and in pre-compiled dll mode, they are already compiled, so these assemblies are no longer needed, and root The directory only needs to refer to the BookStore assembly, and the dependence of the BookStore assembly on these assemblies can be automatically parsed and downloaded in the nupkg file of the dll assembly (this is to be verified).

The above is some content of the new version of the ASP.NET5 project in the release process and related technologies. As you can see from here, ASP.NET5 is completely modularized. IIS is no longer the only container for running MVC programs. Any DNX-compatible running container Both can run MVC programs, and the program release package is divided into two parts, approot and wwwroot, which store application sets (or source code) and static files, so as to achieve better separation. In the next chapter, we will discuss how ASP.NET 5 works.

Note: At present, there is no way to debug by copying the source code, and there is no way to point IIS to the source code for debugging, which will change the development habits of developers.