上海限购,ca1217,宠物虫
本章我们将讲解asp.net5项目发布部署相关的内容，示例项目以我们前一章创建的bookstore项目为例。
发布前的设置
由于新版asp.net5支持多版本dnx运行环境的发布和部署，所以在部署之前，我们需要设定部署的目标dnx（即之前的kre）。
步骤：右键bookstore项目->属性->application选项卡，选择dnx的版本，本例中，选择dnx-coreclr-win-x64.1.0.0-beta4。
在project.json文件的commands节点，我们可以看到，系统默认配置了3个调试命令，分别如下：
| 命令 | 描述 |
|---|---|
| web | 启动weblistener服务，该服务可以让web程序脱离iis运行，默认地址是http://localhost:5000。 |
| gen | 使用该命令可以生成mvc相关的代码，比如controller，目前还用不到。 |
| ef | entity framework迁移命令，用于迁移数据使用，本例我们还用户不到。 |
理论上来说，我们f5运行的时候，应该是启动web命令，但是在vs2015中，默认的运行环境依然是iis express，所以f5调试的时候，会默认启动iis express。
gen参考:
注意：web模式和iis express模式的程序运行端口不一样。
我们先f5调试运行，启动iis express，打开页面，一切正常。重新选择默认模拟器环境为web，再f5运行，这时候发现弹出了一个命令行窗口，并提示如下文字：
[information:microsoft.net.http.server.weblistener] start [information:microsoft.net.http.server.weblistener] listening on prefix: http://localhost:5000/ started
代码没有出错，但是并没有打开浏览器窗口，我们手工打开一个浏览器访问上述网址，即可看到该示例程序的界面，此时说明，该bookstore已经成功运行在5000端口了。其实该模式下的浏览器自动打开功能默认是关闭的，可以通过如下方式开启自动打开功能：
步骤：右键bookstore项目->属性->debug选项卡，勾选launch brower复选框，并在输入框里输入上述网址即可（此时会在项目的properties目录下生成一个debugsettings.json文件来保存上述信息）。
再次f5运行，即可看到自动打开的浏览器界面。
应用程序参数
在该debug选项卡中，我们还看到一个应用程序参数（application arguments）输入框，该输入框可以传入多种参数，这些参数可以在startup.cs里，通过configuration的addcommandline方法进行收集并利用。
环境变量
同理，在debug选项卡的最下面还有一个环境变量（environment variables）输入框，可以让我们在调试的时候自定义一些环境变量的值（key/value），然后通过configuration的addenvironmentvariables方法进行收集并利用。
上述参数和环境变量的具体使用方式，请参考配置信息管理章节。
发布流程分析
在之前的mvc程序中，我们一般都是通过右键项目，选择发布（publish）的方式来发布程序的，这一次我们也来看看这种方式。
首先，右键->发布->profile（选择file system）->选择d:\bookstore->选择release/coreclr->下一步，最终点击发布。在在output面板，我们看到出错了，错误信息如下：
正在连接到 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): 错误 : 错误: 无法识别规则“backuprule”。 c:\program files (x86)\msbuild\microsoft\visualstudio\v14.0\web\microsoft.dnx.publishing.targets(342,5): 错误 : 错误计数: 1。 c:\program files (x86)\msbuild\microsoft\visualstudio\v14.0\web\microsoft.dnx.publishing.targets(342,5): 错误 : 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]。
通过查看输出信息，可以发现，编译成功，但复制的时候出错，可能是powershell的问题，所以返回上述步骤，在设置（settings）选项卡下，将取消发布脚本（publish scripts）下的使用powershell脚本发布的复选框。重新发布，成功了。
打开发布目录d:\bookstore，发现生成了如下目录和文件：
| 目录或文件 | 描述 |
|---|---|
| approot | 应用程序目录 |
| wwwroot | 静态文件目录 |
| gen | linux shell命令文件 |
| gen.cmd | cmd命令文件 |
| web | linux shell命令文件 |
| web.cmd | cmd命令文件 |
看到cmd文件的扩展名，我们可以猜想这些命令是用于执行相关的命令，比如web.cmd可能就是用于启动程序的；而非cmd扩展名文件，我们则猜想可能是用于linux/mac运行的命令。
我们来试一下，点击web.cmd文件，该文件执行以后显示的信息和我们在debug程序时弹出的信息一样，通过访问提示中的网址，我们可以验证应用程序已经正常运行了。这种模式即时我们所说的自宿主（self-host）运行模式。
再试一下iis是否能够运行该程序，将iis站点指向到wwwroot目录，打开网址，也是可以正常访问的。打开wwwroot文件夹进行查看，静态文件一应俱全，但是发现bin目录下并没有我们的项目dll（bookstore.dll），而是多了一个aspnet.loader.dll，而且根目录下还多了一个web.config文件，内容如下:
<?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>
通过查询相关信息（） ，得知aspnet.loader.dll文件只是一个桥接文件，用于接收iis转发过来的请求，然后将其转交给dnx进行运行，这里的web.config里的dnx以及项目信息的配置文件是aspnet.loader.dll在转交请求时所需要的配置信息。
通过配置文件我们可以看到，这里配置了dnx的类型、版本号，程序集的路径和app的路径。打开approot\src\bookstore目录，我们发现，这里居然都是cs源码，虽然有个bin目录，但是里面也没有dll文件。而且在approot\packages文件夹下，居然有90个程序集文件夹（将近30m文件）。
通过查询网站的资料得知（这一部分内容，我们在下一节进行讲解），目前真正运行程序的运行环境是dnx，也被复制到approot\packages\dnx-coreclr-win-x64.1.0.0-beta4目录中， 而该项目依赖的所有程序集（包括system开头的）都被复制到该packages目录下了。目的就是要做到真正的跨平台运行，也就是说，将这些文件复制到linux系统下，只要有对应版本的kre（本例中的dnx是windows版本的）的话，就可以正常运行该程序。
而bin目录下没有dll文件，则是使用了微软最新的动态编译技术，即在运行的过程中，自动编译cs文件，而且一旦修改这些cs文件的话，系统将会自动再次进行编译。（感觉有点像php等脚本语言了）。虽然动态编译很高效，但是还是没有编译好的dll高效，所以微软还提供了一个选项让开发人员在调试的时候生成dll文件。具体步骤如下：
右键bookstore->属性->build选项卡，勾选编译时生成输出（produce outputs on build）复选框。
重新编译程序，发现在bookstore\artifacts\bin\bookstore\debug目录下的2个dnx版本文件夹下都分别生成了bookstore.dll文件了，而且还顺带了nuget的spec文件。
如果在发布的时候也要生成dll文件，则需要在发布（publish）设置里进行修改，步骤如下：
右键bookstore->发布（publish）->settings选项卡->file publish options->勾选precompile during publishing复选框。
这样就可以生成响应的dll文件， 但是这些dll文件依然不在wwwroot/bin目录下，而是在approot\packages\bookstore\1.0.0目录下，在该目录下有2个文件夹，分别是lib和root，以及相关的nuget的spec文件，在lib目录下，生成的是不同dnx版本的dll文件，而root则是类似于之前的web根目录，因为在该目录下除了有视图文件以外，还和以前的结构一样，保留了bin目录，并且在bin目录下的release文件夹下，也有一份针对不同dnx版本的dll文件副本。
提示：上述选择中，另外一个delete all existing files prior to publish也可以勾选上，以便在发布时将之前发布版本的所有文件全部清空。
此时，我们通过web.cmd文件或者iis模式来验证发布的文件，经验证，均可以正常运行。再仔细对比两份不同设在的发布文件，发现，除了dll文件以外，web.config文件的应用程序路径也变了，即从原来的：
<add key="kre-app-base" value="..\approot\src\bookstore" />
变成了如下版本：
<add key="kre-app-base" value="..\approot\packages\bookstore\1.0.0\root" />
而web.cmd文件的内容，也从如下内容：
@"%~dp0approot\packages\dnx-coreclr-win-x64.1.0.0-beta4\bin\dnx.exe" --appbase "%~dp0approot\src\bookstore" microsoft.framework.applicationhost web %*
变成了如下内容：
@"%~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 %*
上述变化，我们是可以理解的，即将src源码动态编译运行的模式修改为预编译dll程序集的模式。所以，在这里我们可以看到，在源码动态编译模式下，其发布后的文件夹结构如下：
我要评论
//源码动态编译模式
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}/.......................
........................................................
而dll预编译模式下的发布文件夹结构如下：
//dll预编译模式
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}/.......................
iis和web.cmd模式的不同
虽然我们对dnx内容的原理不太理解，但有一点内容，我们要记住，那就是两种模式下，对静态文件的访问模式可能不太一样。原因是因为，虽然iis模式的根目录就是存放静态文件的地方，但是web.cmd文件事先启动的却是approot\src\bookstore目录或approot\packages\bookstore\1.0.0\root目录，两个目录下均没有静态文件，因为静态文件时在wwwroot目录下的，我们猜想，在这种模式下，肯定会有一种机制在来映射这些静态文件，通过查找文件发现，在approot\src\bookstore目录下的project.json文件中的webroot键的值，从解决方案中默认的wwwroot变成了"../../../wwwroot"，也就是说kre在映射静态文件的时候，应该是根据这个相对目录来查找这些文件的。
同理，approot\packages\bookstore\1.0.0\root目录下的project.json文件中的webroot键的值，也从wwwroot变成了"../../../../../wwwroot"（因为本来project.json文件的层级就深）。
由于iis是通过aspnet.loader.dll做中转，将请求转交给dnx来运行的，那么在iis模式下，静态文件的请求到底是iis来处理，还是kre来处理呢？我们来验证一下，验证步骤如下：
创建一个wwwroot2文件夹和wwwroot同级，并将wwwrooot目录下的静态文件剪切到wwwroot2目录下。将project.json（如果是预编译模式，则需要修改root目录下的project.json）文件中的webroot值中的wwwroot修改为wwwroot2。继续以iis模式运行该站点
结果发现，静态文件访问不了了（css、js、images均失效了），但我们再通过web.cmd运行时，这些静态文件却又可以访问了。由此得知，在iis模式下，静态文件走的是iis的管线pipeline，而不是dnx的关系pipeline。
两种发布模式下的project.json文件不同
动态编译模式和预编译dll模式这两种模式的自动发布程序，生成后的project.json文件有一些变化，具体变化如下。
动态编译模式
基本上和解决方案里的project.json文件相同，唯一的不同就是webroot的相对路径的修改。
预编译dll模式
原来引用的众多程序集从dependencies节点中移除了，取而代之的是bookstore程序集引用，示例如下：
"dependencies": {
"bookstore": "1.0.0"
},
另外，还多了如下两个节点值（具体功能暂不明确）：
"entrypoint": "bookstore", "loadable": false
猜想，这些不同，可能是因为在动态编译模式下需要引用这些被移除的程序集进行编译，而预编译dll模式下，都已经编译好了，所以就不再需要这些程序集了，而root目录只需要引用bookstore程序集就可以了，而bookstore程序集对这些程序集的依赖，详细在该dll程序集的nupkg文件里是可以自动解析并下载的吧（这一点待验证）。
以上是新版asp.net5项目在发布流程和相关技术的一些内容，从这里大家可以看到，asp.net5是彻底模块化了，iis不再是运行mvc程序的唯一容器，任何兼容dnx的运行容器都可以运行mvc程序，程序发布包被分为approot和wwwroot两个部分，分别存放应用程序集（或源码）和静态文件，从而做到更好的分离。在下一章，我们会讨论，asp.net 5的运行原理。
注意：目前还没有办法通过复制源码的形式来进行调试，同时也没办法将iis指向到源码中进行调试，这将会改变开发人员的开发习惯。
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Net Core Web Api项目与在NginX下发布的方法
asp.net core3.1 引用的元包dll版本兼容性问题解决方案
IdentityServer4实现.Net Core API接口权限认证(快速入门)
ASP.NET Core MVC通过IViewLocationExpander扩展视图搜索路径的实现
网友评论