1、IIS快速浏览
IIS支持在一台服务器上并存多“站点（Sites）”主机。这些站点由IP地址、主机名称、和/或端口号组成。例如假设我的站点是http://www.aspcool.com，它的IP地址为192.197.157.24，主机名称是www.aspcool.com，端口号是80（默认的HTTP端口）。 而Nikhil的站点是http://www.nikhilk.net，它的服务器和我的在同一台Web服务器上，所以和我一样，它拥有192.197.157.24 IP地址和默认的80端口，但是唯一不同就是绑定的主机名称不同。只要这三个之中（IP地址、主机名和端口号）有一个不同，就可以区分每一个站点，进而就可以单独映射到IIS Web服务器
当一个站点经过注册和IIS关联后，你需要建立该站点的主目录，该主目录指出了将来您上传的页面文件的存放地址。当安装IIS时，默认的站点路径主目录映射的是c:\inetpub\wwwroot这个目录，如果你直接放置一个文件，例如test.html在该目录下，你就可以使用http://localhost/test.html来从该web服务器上检索该页面信息。
另外，在该目录下，你可以建立任意多的物理路径和子文件夹，IIS对此都进行了很好的支持。
IIS同样此持虚拟路径（virtual directories，简称vdirs）这一概念，顾名思义，虚拟路径并不是真实的路径，它可以把URL映射成逻辑路径，进而映射到物理离境，这样可以很好的保护文件。
例如，我建立了一个名称为app1 的虚拟路径，并且映射到 c:\inetpub\app1，然后在app1目录下建立了一个名称为test2.htm的文，并结合IIS默认的设置，那么具体用户请求映射如下：
http://localhost/test.html－－－－> c:\inetpub\wwwroot\test.html
http://localhost/app1/test2.htm---->c:\inetpub\app1\test2.htm
注意：上面的wwwroot和app1是平等的，或者说它们在同一文件夹下，所以虽然从URL逻辑上看似乎app1应该在wwwroot目录下，但是其实您并不能够确保实际存放是这样的。
IIS同样支持应用程序（Application）这一概念，这一概念和虚拟路径类似，它们在IIS6版本里还支持管理员来管理堆不同应用程序池的映射。(注意：ASP.NET的应用程序这一概念已经和传统的ASP应用程序的概念不同，它是应用程序的入口)
IIS的Application同样可以映射到主目录下的物理路径，它还可以映射到主目录以外的其他路径。它们能够支持多层次的深度嵌套
例如
http://www.testsite.com/ -> c:\www.testsite.com\wwwroot (应用程序的主目录)
http://www.testsite.com/app1 -> c:\www.testsite.com\app1
http://www.testsite.com/app2 -> c:\www.testsite.com\app2
http://www.testsite.com/app3 -> c:\www.testsite.com\wwwroot\app3
http://www.testsite.com/app3/app4 -> c:\www.testsite.com\wwwroot\app3\app4
注意上面例子里Application的主目录(http://www.testsite.com/) ，app1(http://www.testsite.com/app1)以及app2 (http://www.testsite.com/app2) ，从URL路径上看似乎app1和app2是在主目录下进行继承，但是其实在物理路径上是平等的。
这里特别强调一下，当你在IIS里在右击鼠标选择“建立虚拟路径”时，你其实同时也建立了一个应用程序（Application），（特别的，此时虚拟路径已经自动设置了一些应用程序元数据）
如果你不想要这些应用程序元素，你可以打开刚建立的虚拟目录的属性页，最主要的记住：IIS实现对虚拟路径的绑定，而不是对物理路径的绑定，这一点决定了应用程序的范围和边界。
上面的映射，如果你打开IIS应该类似如下你可以单击删除，这并不会删除虚拟路径，但它会删除应用程序，一般并不建议这么做。
ASP.NET 2.0和应用程序
ASP.NET使用IIS应用程序元数据标示（这些标识存放在IIS元数据配置系统里）来区分每一个应用程序的应用区域，并且关联到具体主机内容，特别的，一个目录被映射成ASP.NET虚拟路径后会做如下一些事情：
（1）它允许在当前应用程序的主目录下建立一个 \bin 文件夹以此来解决汇编程序集合的引用，并可以立即使用它。
（2）它允许应用程序集等级（application-level）可以设置身份验证（具体在web.config里配置）。
（3）它允许全局设置（global.asax）文件定义处理全局等级事件（例如Application_Start/End，以及具体的模块事件如Session_Start/End）
（4）上面这些都在ASP.NET 2.0版本进行了支持，除此以外在ASP.NET2.0版本里，为了部署应用程序的方便和资源共享，它还提供了额外的目录，你可以在应用程序主目录下建立这些额外的目录，这写额外的目录包括App_Data、App_Code等以便提供数据访问、类库的编译和应用程序资源等。
何谓IIS的元数据标识？对于熟悉Windows的用户来说，应该知道windows系统的配置在注册表里，同样IIS也采用了配置文件的思想其配置信息放置在meta数据库里，这就是我们通常称为的元数据库
ASP.NET会建立一个CLR的应用程序区域来处理正在允许应用程序代码的上下文环境。这个应用程序区域时在代码加载策略的设置里（也就是解决应用程序汇编集怎么挂接到 \bin 目录下），以前额外的代码访问权限问题。
使用上面的 www.testsite.com应用程序绑定的例子，这意味这\bin文件夹的位置应该类似如下： c:\www.testsite.com\wwwroot\bin
c:\www.testsite.com\app1\bin
c:\www.testsite.com\app2\bin
c:\www.testsite.com\wwwroot\app3\bin
c:\www.testsite.com\wwwroot\app3\app4\bin
\app1运行时的代码会使用\app1\bin文件夹的汇编集。
\wwwroot\app3 运行时的代码会使用\wwwroot\app3 \bin 文件下的汇编集
\wwwroot文件夹下的运行时代码（注意不是\wwwroot\app3目录下）将使用\wwwroot\bin文件夹下的代码来加载汇编集
注意：这些汇编集是由.NET框架ASP.NET V1,V1.1和V2.0进行区分的
使用Visual Studio.NET 2005
重要说明：在下面的介绍了，我们使用了Visual Web Express2005来开发ASP.NET2.0。VWE2005是Visual Stduio.NET2005的一部分，虽然VS.NET2005功能很强大，但是根据应用情况（例如有些人用C#版，就不用安装VB版本）有许多功能其实并不需要，所以这里说的VS2005其实是VWE2005，您可以到 http://www.asp.net 免费下载
VS2005支持多种方式来打开和编辑ASP.NET应用程序。总体概括起来有四种方式：File System、Local IIS、FTP Site和Remote Site。如下图
本节主要介绍Local IIS，其它方式以后会介绍。
有些人可能会问如果如果使用Local IIS，你打开一个web站点时，该站点有多个嵌套的子应用程序怎么办？例如当你打开www.testsite.com(应用程序根目录)，而根目录下包含多个子应用程序（(www.testsite.com/app1, www.testsite.com/app2, 和 www.testsite.com/app3），一个广为关注的问题就是VS2005会不会将所有的子目录整合在一起，因为绑定的应用程序和项目会编译在\bin目录下（而事实上\bin目录和这四个应用程序应该不同）。
一个非常好的消息是VS2005能够正确的获取每一个应用程序界定范围，也就是说当你打开一www.testsite.com应用程序的时候，你在VS2005里打开的项目看起来类似如下
从解决方案资源管理器里可以看到，VS2005只包含在www.testsite.com应用程序里夹，和应用程序的子文件夹（例如上面的subdirectory1和subdirectory2）。 这样当你使用VS2005进行编译时，它仅仅编译包含在www.testsite.com应用程序里面的文件（注意这里不包括子应用程序）。而如果你部署该web项目，你页将仅仅部署这些在www.testsite.com的主应用程序（不包括子应用程序）。这其实和VS2003是一样的。
另外VS2005进一步改善了在资源管理器里嵌套的应用程序的图标的显示，（请参考上面的app1，App2和app3的图标），这些图标能够让开发人员识别这些应用程序在web逻辑空间里它们是子应用程序，而并不是开发时的具体文件存放位置。
这些子应用程序并不包含具体的内容（这和VS2003类似），所以你并不能够展开它们的内容，因为它们的设计目的是让你知道那里有这样一个子应用程序，目的是可以快速帮助你理解整个应用的体现结构。
另外还有一点需要注意，在上面app3种被映射到c:\www.testsite.com\wwwroot\app3物理路径，它直接是在主目录 www.testsite.com应用程序（c:\www.testsite.com\wwwroot\）下，可是它被标记为应用程序，所以当你编译www.testsite.com项目时，他会排斥编译app3应用程序到主应用程序里，而subdirectory1和subdirectory2并为标记为应用程序，它将作为主目录的一部分编译到主应用程序里。
另外一个工作流程改进点是VS2005允许你通过双击子应用程序图标来添加项目。当你在子应用程序上双击（例如在app3上双击）将弹出打开web站点对话框，如图，他会问你时打开该app3应用程序（这将关闭当前www.testsite.com应用程序）还是将该app1应用程序添加到当前www.testsite.com应用程序。
例如我选择“add the web site to the current solution”,然后单击OK，这样你的解决方法资源管理器将被分为两个项目，看起来如下
例如 我选择“add the web site to the current solution”，这样当我在解决方案资源管理器单击app3图标时，它就出现如下
你可以象使用VS2003的同样方式那样来使用VS2005管理Web应用程序以及子应用程序。比较典型的的子应用程序嵌套的例子是包含一个Web项目和一个或者多个类库。
在下面的这个示意图是一个包含了三层体现结构的应用程序：一个web项目、一个或者多个类库等。我在这个解决方案里增加了数据访问层（Data Access Layer，DAL）和业务逻辑层（Business Logic Layer，BLL）。
接下来，你就可以设置项目之间的引用和编译的依赖管理，例如上面的这个例子依赖关系如下：
这样BLL层建立在DAL的基础上，而http://localhost:81/则建立在BLL基础上，这种依赖关系决定了系统编译的顺序为：先编译DAL、然后编译BLL最后编译http://localhost:81 这个Web项目。
我接下来就可以直接保保存我的解决方案，这个解决方法封装了所有的项目（包括项目之间的相互引用和依赖关系），在这方面它和和VS2003是类似的，以后我只要打开该解决方案，系统将子定加载所有的项目和资源、文件。
当以后我发以后发布Web站点时，它会将DAL、BLL和Web项目的整体结果整合在一起编译成二进制文件，因此当我发布web网站时，你并不需要DAL和BLL项目。
（关于上面DAL、BLL等具体的实际应用您可以参考《ASP.NET技术详解与应用实例》的最后一章）
使用ASP.NET2.0版本
最后在说一下ASP.NET的版本问题。正如Visual Stuido.NET2003和.NET Framework V1.1配合的很好一样，Visual Studio.NET 2005和.NET Framework V2.0同样协调的也很好。这意味这VS2003和VS2005可以装在同一台机器上。原有的项目您仍然可以使用VS2003继续开发，而新的项目你可以选择使用VS2005进行开发。
这也意味这你可以选择你的ASP.NET应用程序在web服务器上的运行版本，您可以让有些应用程序运行在ASP.NET1.1版本上，有些运行在ASP.NET2.0版本。也就是说，你可以自行决定.NET运行版本的控制。
默认的如果你以前在你的机器上安装了ASP.NET1.1版本，然后又安装ASP.NET2.0后，一般你也不会考虑立刻更改应用程序并升级到最新的版本，相反你可能想自行决定应用程序的使用的版本，正式由于这个原因，因此当你安装ASP.NET2.0时，系统并不会更改您的默认设置，而仍然使用ASP.NET1.1版本。
为了实现.NET版本控制的功能，系统是通过使用IIS新增加的“ASP.NET”页标签来实现的，ASP.NET页标签是在我们安装.NET2.0版本时自动添加的。在根目录的属性力，可以设置默认全局应用程序版本如下图，除此以外该页标签自动添加在任意一个应用程序的属性里，这页允许我们可以单独设置每一个应用程序的使用版本。
这里需要强调一下“级联”性质，以前叙为例子，如果我将app2设置为使用.NET 2.0，那么此时app3如果是.NET1.1版本，则保持不变，因为app2和app3是并列的；
然而如果我将app3设置为.NET2.0，由于app4默认丛属于app3，所以如果原先app4是.NET1.1版本，则会更新为.NET2.0版本。
