【移动应用开发技术】asp.net项目发布与部署的方法

【移动应用开发技术】项目发布与部署的方法

这篇文章主要介绍“项目发布与部署的方法”的相关知识，在下通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“项目发布与部署的方法”文章能帮助大家解决问题。发布前的设置由于新版ASP.NET5支持多版本DNX运行环境的发布和部署，所以在部署之前，我们需要设定部署的目标DNX（即之前的KRE）。步骤：右键BookStore项目->属性->Application选项卡，选择DNX的版本，本例中，选择dnx-coreclr-win-x-beta4。在project.json文件的commands节点，我们可以看到，系统默认配置了3个调试命令，分别如下：命令描述web启动WebListener服务，该服务可以让web程序脱离IIS运行，默认地址是http://localhost:5000。gen使用该命令可以生成MVC相关的代码，比如Controller，目前还用不到。ef

EntityFramework迁移命令，用于迁移数据使用，本例我们还用户不到。理论上来说，我们F5运行的时候，应该是启动web命令，但是在VS2015中，默认的运行环境依然是IISExpress，所以F5调试的时候，会默认启动IISExpress。gen参考:/dudu/p/aspnet5-k-gen.html注意：web模式和IISExpress模式的程序运行端口不一样。我们先F5调试运行，启动IISExpress，打开页面，一切正常。重新选择默认模拟器环境为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选项卡，勾选LaunchBrower复选框，并在输入框里输入上述网址即可（此时会在项目的Properties目录下生成一个debugSettings.json文件来保存上述信息）。再次F5运行，即可看到自动打开的浏览器界面。应用程序参数在该Debug选项卡中，我们还看到一个应用程序参数（ApplicationArguments）输入框，该输入框可以传入多种参数，这些参数可以在Startup.cs里，通过Configuration的AddCommandLine方法进行收集并利用。环境变量同理，在Debug选项卡的最下面还有一个环境变量（EnvironmentVariables）输入框，可以让我们在调试的时候自定义一些环境变量的值（key/value），然后通过Configuration的AddEnvironmentVariables方法进行收集并利用。上述参数和环境变量的具体使用方式，请参考配置信息管理章节。发布流程分析在之前的MVC程序中，我们一般都是通过右键项目，选择发布（Publish）的方式来发布程序的，这一次我们也来看看这种方式。首先，右键->发布->Profile（选择FileSystem）->选择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）选项卡下，将取消发布脚本（PublishScripts）下的使用PowerShell脚本发布的复选框。重新发布，成功了。打开发布目录D:\BookStore，发现生成了如下目录和文件：目录或文件描述approot

应用程序目录wwwroot

静态文件目录genlinuxshell

命令文件gen.cmdcmd

命令文件weblinuxshell

命令文件web.cmdcmd

命令文件看到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-x-beta4目录中，而该项目依赖的所有程序集（包括System开头的）都被复制到该packages目录下了。目的就是要做到真正的跨平台运行，也就是说，将这些文件复制到linux系统下，只要有对应版本的KRE（本例中的DNX是Windows版本的）的话，就可以正常运行该程序。而bin目录下没有dll文件，则是使用了微软***的动态编译技术，即在运行的过程中，自动编译cs文件，而且一旦修改这些cs文件的话，系统将会自动再次进行编译。（感觉有点像php等脚本语言了）。虽然动态编译很高效，但是还是没有编译好的dll高效，所以微软还提供了一个选项让开发人员在调试的时候生成dll文件。具体步骤如下：右键BookStore->属性->Build选项卡，勾选编译时生成输出（Produceoutputsonbuild）复选框。重新编译程序，发现在BookStore\artifacts\bin\BookStore\Debug目录下的2个DNX版本文件夹下都分别生成了BookStore.dll文件了，而且还顺带了Nuget的spec文件。如果在发布的时候也要生成dll文件，则需要在发布（Publish）设置里进行修改，步骤如下：右键BookStore->发布（Publish）->Settings选项卡->FilePublishOptions->勾选Precompileduringpublishing复选框。这样就可以生成响应的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文件副本。提示：上述选择中，另外一个Deleteallexistingfilespriortopublish也可以勾选上，以便在发布时将之前发布版本的所有文件全部清空。此时，我们通过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-x-beta4\bin\dnx.exe"

--appbase

"%~dp0approot\src\BookStore"

Microsoft.Framework.ApplicationHost

web

%*变成了如下内容：@"%~dp0approot\packages\kre-coreclr-win-x-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来处理呢？我们来验证一下，