Interpreting ASP 5 & MVC6 Series (3): Project Release and deployment

Original: Interpretation of ASP. 5 & MVC6 Series (3): Project Release and deployment

In this chapter we will talk about the ASP.NET5 Project release deployment, which is an example of the bookstore project created in our previous chapter.

Pre-release settings

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

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

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

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

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

Gen Reference: http://www.cnblogs.com/dudu/p/aspnet5-k-gen.html
Note: The Web mode and IIS Express mode are not the same as the programs that run the ports.

We first F5 debug run, start IIS Express, open the page, everything is OK. Re-select the default emulator environment for the web, then F5 run, this time the discovery popup a 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 did not go wrong, but did not open the browser window, we manually open a browser to access the above URL, we can see the interface of the sample program, it shows that the bookstore has successfully run on port 5000. In fact, the mode of the browser auto-open function is turned off by default, you can turn on the auto-open function as follows:

Steps: Right-bookstore Item--Properties->debug tab, tick launch brower check box, and enter the above URL in the input box (this will generate a Debugsettings.json file in the project's properties directory to hold the above information).

Once again F5 run, you can see the Automatically open browser interface.

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

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

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

Release Process Analysis

In the previous MVC program, we usually publish the program by right-clicking the project and choosing Publish (Publish), this time we also look at this way.

First, right-click Publish->profile (choose File System), select D:\BookStore Release/coreclr and Next, and then end with publish. In the output panel, we see an error with the following message:

  is 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" is not 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, it can be found that the compilation succeeds, but the error occurred while copying, it may be PowerShell problem, so return to the above steps, under the Setup (Settings) tab, the script will be unpublish (Publish Scripts), use the PowerShell script to publish the check box. Re-released, successful.

Open the Publish directory D:\BookStore and find 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 cmd file extension, we can guess that these commands are used to execute related commands, such as web.cmd may be used to start the program, rather than the cmd extension file, we guess it might be used for Linux/mac Run command.

Let's try it, click on the web.cmd file, the file will be displayed after the message and we in the Debug program pop-up information, by accessing the URL in the prompt, we can verify that the application has been working properly. This mode is immediately what we call the self-host (self-host) run mode.

Try again if IIS is able to run the program, point the IIS site to the wwwroot directory, open the URL, and you can access it normally. Open the wwwroot folder for viewing, static files are readily available, but found that the bin directory does not have our project DLL ( BookStore.dll ), but there is one more AspNet.Loader.dll , and the root directory also has a web.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 the relevant information (access details), AspNet.Loader.dll it is known that the file is just a bridging file for receiving requests forwarded by IIS, and then handing it over to dnx run, where the web.config dnx and the configuration file for the project information are the AspNet.Loader.dll configuration information needed to transfer the request.

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

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

And the bin directory does not have DLL files, is the use of Microsoft's latest dynamic compilation technology, that is, in the process of running, automatically compile CS files, and once the CS files are modified, the system will be automatically compiled again. (It feels a bit like a scripting language such as PHP). Although dynamic compilation is efficient, it is not as efficient as a compiled DLL, so Microsoft also provides an option for developers to generate DLL files when debugging. The 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 by the BookStore.dll file, but also incidentally the NuGet spec file.

If you want to generate DLL files at the time of publishing, you will need to modify them in the release (Publish) settings as follows:

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

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

Tip: In the above selection, the other delete all existing files prior to publish can also be ticked so that all files from the previous release will be emptied at the time of publication.

At this point, we verify the published files through the Web.cmd file or IIS mode, which is verified to work correctly. After a careful comparison of two different published files, it was found that the application path of the Web. config file, in addition to the DLL file, 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 SRC source code dynamic compilation run mode modified to precompiled DLL assembly mode. So, here we can see, in the source code dynamic compilation mode, its post-release folder structure is as follows:

//源码动态编译模式wwwroot/bin/Microsoft.AspNet.Loader.IIS.dllwwwroot/Contents/site.csswwwroot/Contents/...............................................................................................wwwroot/Scripts/jquery.jswwwroot/Scripts/........................................................................................................................................................approot/src/BootStore/project.jsonapproot/src/BootStore/...............................approot/src/BootStore.Data/project.jsonapproot/src/BootStore.Data/..............................approot/src/BootStore.Bussiness/project.jsonapproot/src/BootStore.Bussiness/.........................approot/packages/Elmah/{version}/...............................................................................

The Publish folder structure in the DLL precompilation mode is as follows:

//dll预编译模式wwwroot/bin/Microsoft.AspNet.Loader.IIS.dllwwwroot/Contents/site.csswwwroot/Contents/...............................................................................................wwwroot/Scripts/jquery.jswwwroot/Scripts/........................................................................................................................................................approot/packages/BootStore/{version}/...................approot/packages/BootStore.Data/{version}/..............approot/packages/BootStore.Bussiness/{version}/.........approot/packages/Elmah/{version}/.......................

IIS and Web.cmd modes are different

Although we do not understand the principle of dnx content, but one thing, we have to remember, that is, in both modes, the access mode for a static file may not be the same. The reason is because, although the IIS mode root directory is the place to hold static files, but the Web.cmd file started in advance is a approot\src\BookStore directory or approot\packages\BookStore\1.0.0\root directory, two directories do not have static files, because static files in the wwwroot directory, we guess, in this mode, There will certainly be a mechanism to map these static files, by finding the files found in the directory, the value of the key in the file, from the default in the approot\src\BookStore project.json webroot solution wwwroot becomes "../../../wwwroot" , that is, kre in the mapping of static files, It should be based on this relative directory to find these files.

In the same vein, the approot\packages\BookStore\1.0.0\root project.json value of the key in the file under the directory webroot also wwwroot becomes "../../../../../wwwroot" (because the hierarchy of the original project.json file is deep).

Because IIS is passing the AspNet.Loader.dll request to Dnx to run, in IIS mode, is the request for the static file to be handled by IIS or Kre? Let's verify that the verification steps are as follows:

1. Create a wwwroot2 folder and wwwroot sibling, and wwwrooot cut the static files under the directory into the wwwroot2 directory.
   
2. Will project.json (if it is precompiled mode, you need to modify the Project.json in the root directory) file to modify the value in the webroot wwwroot wwwroot2 .
   
3. Continue to run the site in IIS mode

The results found that the static file access is not (CSS, JS, images are not valid), but we again through the Web.cmd runtime, these static files can be accessed again. It is learned that in IIS mode, the static file goes to the IIS pipeline Pipeline, not the DNX relationship pipeline.

Different Project.json files in two release modes

Dynamic compilation mode and precompiled DLL mode are the two modes of automatic publishing program, after the generated Project.json file has 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 relative path of the Webroot.

Pre-compiled DLL mode
The many assemblies originally referenced were removed from the dependencies node and replaced by the Bookstore assembly reference, as shown in the following example:

  "dependencies": {    "BookStore": "1.0.0"  },

In addition, there are more than two node values (specific function is not clear):

  "entryPoint": "BookStore",  "loadable": false

Conjecture, these differences may be due to the need to reference these removed assemblies in the dynamic compilation mode, and the precompiled DLL mode is compiled, so the assemblies are no longer needed, and the root directory only needs to refer to the bookstore assembly. The bookstore assembly's dependency on these assemblies, detailed in the DLL assembly's nupkg file, is automatically parsed and downloaded (this is to be verified).

The above is a new version of the ASP.NET5 project in the release process and some of the relevant technology, from here you can see, 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, respectively, to store the application set (or source code) and static files, so as to achieve better separation. In the next chapter, we'll discuss how ASP. NET 5 works.

Note: 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.

Synchronization and recommendations

This article has been synchronized to the Catalog index: Interpreting ASP. & MVC6 Series

Interpreting ASP 5 & MVC6 Series (3): Project Release and deployment