//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文件事先启动的却是approotsrcBookStore目录或approotpackagesBookStore1.0.0root目录，两个目录下均没有静态文件，因为静态文件时在wwwroot目录下的，我们猜想，在这种模式下，肯定会有一种机制在来映射这些静态文件，通过查找文件发现，在approotsrcBookStore目录下的project.json文件中的webroot键的值，从解决方案中默认的wwwroot变成了"../../../wwwroot"，也就是说kre在映射静态文件的时候，应该是根据这个相对目录来查找这些文件的。
同理，approotpackagesBookStore1.0.0root目录下的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文件有一些变化，具体变化如下。
动态编译模式
