Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of "asp.net project release and deployment methods". The editor shows you the operation process through an actual case. The operation method is simple, fast and practical. I hope this article "asp.net project release and deployment methods" can help you solve the problem.

Settings before publishing

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

Step: right-click the BookStore project-> Properties-> Application tab, and select the version of DNX. In this case, 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 debug commands configured by default, one of which is as follows:

Command description

Web starts the WebListener service, which allows web programs to run without IIS, and the default address is http://localhost:5000.

Gen uses this command to generate MVC-related code, such as Controller, which is not currently needed.

Ef Entity Framework migration command, used to migrate data for use, we do not have users in this example.

In theory, when we run F5, we should start the web command, but in VS2015, the default runtime environment is still IIS Express, so when F5 debugging, it will start IIS Express 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 F5 debug run, start IIS Express, open the page, everything is normal. Reselect the default simulator environment to web, and then run it on F5. A command line window pops up and prompts you with 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 does not open the browser window, we manually open a browser to visit the above URL, we can see the interface of the sample program, which shows that the BookStore has been successfully run on port 5000. In fact, the automatic opening feature of the browser in this mode is turned off by default, and can be enabled by the following ways:

Step: 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 the above information).

Run F5 again and you will see the browser interface that opens automatically.

Application parameters

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

Environment variable

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

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

Release process analysis

In the previous MVC program, we usually release the program by right-clicking the project and choosing to Publish, this time let's take a look at this way.

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

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 BackupRule 5): error: error: the rule "BackupRule" is not recognized. C:\ Program Files (x86)\ MSBuild\ Microsoft\ VisualStudio\ v14.0\ Web\ Microsoft.DNX.Publishing.targets: error: error count: 1. C:\ Program Files (x86)\ MSBuild\ Microsoft\ VisualStudio\ v14.0\ Web\ Microsoft.DNX.Publishing.targets: 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 during replication, which may be a problem with powershell, so go back to the above steps and under the Settings tab, the check box under Publish Scripts using PowerShell script will be unpublished. Reissue, it's a success.

Open the release directory D:\ BookStore and find that the following directories and files have been 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 these commands may be used to run linux/mac.

Let's give it a try and click on the web.cmd file, which displays the same message as the one we popped up in the Debug program. By visiting the URL in the prompt, we can verify that the application is working properly. This mode is immediately what we call the Self-Host operation mode.

Try again whether IIS can run the program, point the IIS site to the wwwroot directory, open the URL, and you can access it normally. Open the wwwroot folder and find all the static files available, but we found that there is not our project DLL (BookStore.dll) in the bin directory, but an AspNet.Loader.dll is added, and a web.config file is added to the root directory, as shown below:

By querying the relevant information (access details), we know that the AspNet.Loader.dll file is only a bridge file, which is used to receive the request forwarded by IIS, and then transfer it to dnx for operation. Here, the dnx in web.config and the configuration file of project information are the configuration information needed by AspNet.Loader.dll when transferring the request.

We can see from the configuration file that the type of dnx, the version number, the path of the assembly, and the path of the app are configured. Open the approot\ src\ BookStore directory, and we find 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).

According to the information on the website (which we will explain in the next section), the real running environment of 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 at the beginning of System) are copied to this packages directory. The goal is to achieve true cross-platform operation, that is, to copy these files to the linux system, as long as there is a corresponding version of KRE (in this case, the DNX is the Windows version), you can run the program normally.

If there are no dll files in the bin directory, Microsoft's dynamic compilation technology is used, that is, the cs files are compiled automatically during the run process, and once these cs files are modified, the system will compile again automatically. It feels a bit like scripting languages such as php. Although dynamic compilation is efficient, it is not as efficient as compiled dll, so Microsoft also provides an option for developers to generate dll files while debugging. The specific steps are as follows:

Right-click the BookStore- > Properties-> Build tab and check the generate output at compile time (Produce outputs on build) check box.

Recompile the program and find that the BookStore.dll file has been generated under the two DNX version folders in the BookStore\ artifacts\ bin\ BookStore\ Debug directory, along with the spec file of Nuget.

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

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

In this way, the dll files for the response 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, where there are two folders, lib and root, and the related Nuget spec files. In the lib directory, different dnx versions of dll files are generated, while root is similar to the previous web root directory. Because there are not only view files in this directory, but also the same structure as before, 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: of the above choices, another Delete all existing files prior to publish can also be checked to empty all files from previous releases at the time of release.

At this point, we use the web.cmd file or IIS mode to verify that the published file can run normally. After carefully comparing the two different release files, it is found that in addition to the dll file, the application path of the web.config file has also changed, that is, from the original:

Changed to the following version:

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

@ "% ~ 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% *

The above changes are understandable, that is, the mode of dynamic compilation and operation of src source code is changed to the mode of precompiled dll assemblies. So, here we can see that in the dynamic compilation mode of source code, the released folder structure 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, one thing to keep in mind is that the access patterns for static files may not be the same in the two modes. The reason is that although the root directory of IIS mode is the place where static files are stored, web.cmd files are launched in advance in the approot\ src\ BookStore directory or approot\ packages\ BookStore\ 1.0.0\ root directory, and there are no static files in either directory, because static files are in the wwwroot directory. We suspect that in this mode, there must be a mechanism to map these static files and find them by looking for files. 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 kre should look for static files based on this relative directory when mapping them.

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

Since IIS runs through AspNet.Loader.dll and transfers the request to DNX, in IIS mode, is the request for static files handled 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 the wwwroot in the webroot value in the project.json (if it is in precompiled 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 are not accessible (CSS, JS, Images are all invalid), but when we run through web.cmd, these static files can be accessed again. From this, we know that in IIS mode, static files follow IIS's pipeline Pipeline, not DNX's relational Pipeline.

Project.json files are different in the two release modes

Dynamic compilation mode and pre-compiled dll mode of the automatic release program, 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 webroot.

Precompiled dll mode

Many of the original referenced assemblies are removed from the dependencies node and replaced by BookStore assembly references, as shown in the following example:

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

In addition, the following two node values have been added (the specific function is not clear yet):

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

It is speculated that these differences may be due to the fact that these removed assemblies need to be referenced for compilation in dynamic compilation mode, while in precompiled dll mode, these assemblies are no longer needed, while the root directory only needs to reference BookStore assemblies, and BookStore assemblies depend on these assemblies. The details can be parsed and downloaded automatically in the nupkg file of the dll assembly (this needs to be verified).

This is the end of the introduction to "methods for the release and deployment of asp.net projects". Thank you for reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.