Project release and deployment

Pre-publishing setup

Since the new version of ASP.NET 5 supports the release and deployment of multiple versions of DNX runtime environment, we need to set the target DNX (the previous KRE) for deployment before deployment.

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

In the commands node of the project.json file, we can see that the system has three debugging commands configured by default, as follows:
Command Description
web starts the WebListener service, which allows web programs to run independently of IIS. The default address is http://localhost:5000.
gen Use this command to generate MVC related code, such as Controller, which is not used yet.
ef Entity Framework migration commands are used to migrate data. We cannot use them 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 debugging with F5, IIS Express will be started by default.

gen reference: http://www.cnblogs.com/dudu/p/aspnet5-k-gen.html
Note: The program running ports in web mode and IIS Express mode are different.

We first debug and run by pressing F5, start IIS Express, open the page, and everything is normal. Reselect the default simulator environment as web, and run again by pressing F5. At this time, a command line window pops up, and the following text is prompted:

 [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 visit the above URL, and we can see the interface of the sample program. This means that the BookStore has successfully run on port 5000. In fact, the automatic opening function of the browser in this mode is disabled by default. You can enable the automatic opening function in the following way:

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

Press F5 again and you will see the browser interface open automatically.

Application Arguments <br /> In the Debug tab, we also see an Application Arguments input box, which 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 <br /> Similarly, there is an Environment Variables input box at the bottom of the Debug tab, which allows us to customize the values ​​of some environment variables (key/value) during debugging, and then collect and use them through the AddEnvironmentVariables method of Configuration.

For the specific usage of the above parameters and environment variables, please refer to the Configuration Information Management section.

Release process analysis

In previous MVC programs, we usually 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: 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 occurred 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 checking the output information, we can find that the compilation is successful, but an error occurs when copying. This may be a PowerShell problem, so we return to the above steps and uncheck the box "Publish using PowerShell script" under the Settings tab. We publish again and it succeeds.

Open the release 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, such as web.cmd may be used to start the program; instead of the cmd extension file, we guess that it may be a command for running on Linux/Mac.

Let's try it out. Click on the web.cmd file. The information displayed after the file is executed is the same as the information that pops up when we debug the 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 running mode.

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

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

By checking the information on the website (we will explain this part in the next section), the actual operating environment for the program is DNX, which is also copied to the approot\packages\dnx-coreclr-win-x64.1.0.0-beta4 directory, and all the assemblies that the project depends on (including those starting with System) are copied to the packages directory. The purpose is to achieve true cross-platform operation, that is, copy these files to the Linux system, as long as there is a corresponding version of KRE (DNX in this case is the Windows version), the program can run normally.

The fact that there is no dll file in the bin directory is because Microsoft's latest dynamic compilation technology is used, that is, the CS files are automatically compiled during the running process, and once these CS files are modified, the system will automatically compile again. (It feels a bit like PHP and other scripting languages). Although dynamic compilation is very efficient, it is still not as efficient as compiled dll, so Microsoft also provides an option for developers to generate dll files during debugging. The specific steps are as follows:

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

Recompile the program and find that BookStore.dll files are generated in the two DNX version folders under the BookStore\artifacts\bin\BookStore\Debug directory, and Nuget's spec file is also generated.

If you also 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 checkbox.

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, which has two folders, lib and root, as well as related Nuget spec files. In the lib directory, dll files of different dnx versions are generated, and the root is similar to the previous web root directory, because in addition to the view files, the bin directory is retained as before, and there is also a copy of the dll files for different dnx versions in the Release folder under the bin directory.

Tip: In the above options, you can also check Delete all existing files prior to publish to clear all files of the previously published version when publishing.

At this point, we verify the published files through the web.cmd file or IIS mode, and it is verified that they can run normally. After carefully comparing the two published files with different settings, we 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 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 as follows:

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

It 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 %*

We can understand the above changes, that is, changing the src source code dynamic compilation mode to the pre-compiled dll assembly mode. So, here we can see that in the source code dynamic compilation mode, the folder structure after 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 release folder structure in dll precompilation mode is as follows: 
 
 //dll precompilation 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}/.............................

Differences between IIS and web.cmd modes

Although we don't quite understand the principle of dnx content, there is one thing we need to remember, that is, the access mode of static files in the two modes may be different. The reason is that although the root directory of IIS mode is where static files are stored, the web.cmd file is pre-started in the approot\src\BookStore directory or the approot\packages\BookStore\1.0.0\root directory. There are no static files in both directories, because static files are in the wwwroot directory. We guess that in this mode, there must be a mechanism to map these static files. By searching the file, we found that the value of the webroot key in the project.json file in the approot\src\BookStore directory has changed from the default wwwroot in the solution to "../../../wwwroot", which means that when kre maps static files, it should find these files based on this relative directory.

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

Since IIS transfers the request to DNX through AspNet.Loader.dll, in IIS mode, is the request for static files processed by IIS or KRE? Let's verify it. The verification steps are as follows:

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

It turns out that static files are inaccessible (CSS, JS, and Images are all invalid), but when we run it again through web.cmd, these static files are accessible again. From this, we know that in IIS mode, static files go through the IIS pipeline, not the DNX pipeline.
The project.json files are different for the two release modes

There are some changes in the project.json file generated by the automatic publishing program in the dynamic compilation mode and pre-compiled dll mode. The specific changes are as follows.

Dynamic compilation mode <br /> Basically the same as the project.json file in the solution, the only difference is the modification of the relative path of webroot.

Precompiled dll mode <br /> The original referenced assemblies are removed from the dependencies node and replaced by the BookStore assembly reference, as shown below:

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

In addition, there are two more node values ​​(the specific functions are not yet clear):

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

It is speculated that these differences may be because in dynamic compilation mode, it is necessary to reference these removed assemblies for compilation, while in precompiled dll mode, they are all compiled, so these assemblies are no longer needed, and the root directory only needs to reference the BookStore assembly. The dependency of the BookStore assembly on these assemblies can be automatically parsed and downloaded in detail in the nupkg file of the dll assembly (this needs to be verified).

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

Note: There is currently 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.