再试一下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="..approotpackages" /> <add key="dnx-version" value="1.0.0-beta4" /> <add key="dnx-clr" value="coreclr" /> <add key="dnx-app-base" value="..approotsrcBookStore" /> </appSettings> </configuration>
通过查询相关信息（访问详情） ，得知AspNet.Loader.dll文件只是一个桥接文件，用于接收IIS转发过来的请求，然后将其转交给dnx进行运行，这里的web.config里的dnx以及项目信息的配置文件是AspNet.Loader.dll在转交请求时所需要的配置信息。
通过配置文件我们可以看到，这里配置了dnx的类型、版本号，程序集的路径和app的路径。打开approotsrcBookStore目录，我们发现，这里居然都是cs源码，虽然有个bin目录，但是里面也没有dll文件。而且在approotpackages文件夹下，居然有90个程序集文件夹（将近30M文件）。
通过查询网站的资料得知（这一部分内容，我们在下一节进行讲解），目前真正运行程序的运行环境是DNX，也被复制到approotpackagesdnx-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）复选框。
重新编译程序，发现在BookStoreartifactsbinBookStoreDebug目录下的2个DNX版本文件夹下都分别生成了BookStore.dll文件了，而且还顺带了Nuget的spec文件。
如果在发布的时候也要生成dll文件，则需要在发布（Publish）设置里进行修改，步骤如下：
