IIS和ASP.NET2.0
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版本。