看到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 %*