支持asp的web服务器有，不能作为web服务器的是

老铁们，大家好，相信还有很多朋友对于支持asp的web服务器有和不能作为web服务器的是的相关问题不太懂，没关系，今天就由我来为大家分享分享支持asp的web服务器有以及不能作为web服务器的是的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！

几种常用的Web服务器

1. Tomcat

Tomcat是一个开放源代码、运行servlet和JSP Web应用软件的基于Java的Web应用软件容器。Tomcat Server是根据servlet和JSP规范进行执行的，因此我们就可以说Tomcat Server也实行了Apache-Jakarta规范且比绝大多数商业应用软件服务器要好。

Tomcat是Java Servlet2.2和JavaServerPages 1.1技术的标准实现，是基于Apache许可证下开发的自由软件。Tomcat是完全重写的Servlet API 2.2和JSP 1.1兼容的Servlet/JSP容器。Tomcat使用了JServ的一些代码，特别是Apache服务适配器。随着Catalina Servlet引擎的出现，Tomcat第四版号的性能得到提升，使得它成为一个值得考虑的Servlet/JSP容器，因此目前许多WEB服务器都是采用Tomcat。

2. JBOSS

JBoss是全世界开发者共同努力的成果，一个基于J2EE的开放源代码的应用服务器。因为JBoss代码遵循LGPL许可，你可以在任何商业应用中免费使用它，而不用支付费用。JBoss是一个管理EJB的容器和服务器，支持EJB 1.1、EJB 2.0和EJB3.0的规范。但JBoss核心服务不包括支持servlet/JSP的WEB容器，一般与Tomcat或Jetty绑定使用。

3. IBM WebSphere

WebSphere软件平台能够帮助客户在Web上创建自己的业务或将自己的业务扩展到Web上，为客户提供了一个可靠、可扩展、跨平台的解决方案。作为IBM电子商务应用框架的一个关键组成部分，WebSphere软件平台为客户提供了一个使其能够充分利用Internet的集成解决方案。

WebSphere软件平台提供了一整套全面的集成电子商务软件解决方案。作为一种基于行业标准的平台，它拥有足够的灵活性，能够适应市场的波动和商业目标的变化。它能够创建、部署、管理、扩展出强大、可移植、与众不同的电子商务应用，所有这些内容在必要时都可以与现有的传统应用实现集成。以这一稳固的平台为基础，客户可以将不同的IT环境集成在一起，从而能够最大程度地利用现有的投资。

WebSphere针对以 Web为中心的开发人员，他们都是在基本 HTTP服务器和 CGI编程技术上成长起来的。IBM将提供 WebSphere产品系列，通过提供综合资源、可重复使用的组件、功能强大并易于使用的工具、以及支持 HTTP和 IIOP通信的可伸缩运行时环境，来帮助这些用户从简单的 Web应用程序转移到电子商务世界。

4. BEA WebLogic

BEA WebLogic Server是一种多功能、基于标准的web应用服务器，为企业构建自己的应用提供了坚实的基础。各种应用开发、部署所有关键性的任务，无论是集成各种系统和数据库，还是提交服务、跨 Internet协作，起始点都是 BEA WebLogic Server。由于它具有全面的功能、对开放标准的遵从性、多层架构、支持基于组件的开发，基于Internet的企业都选择它来开发、部署最佳的应用。

BEA WebLogic Server在使应用服务器成为企业应用架构的基础方面继续处于领先地位。BEAWebLogic Server为构建集成化的企业级应用提供了稳固的基础，它们以 Internet的容量和速度，在连网的企业之间共享信息、提交服务，实现协作自动化。BEA WebLogic Server的遵从 J2EE、面向服务的架构，以及丰富的工具集支持，便于实现业务逻辑、数据和表达的分离，提供开发和部署各种业务驱动应用所必需的底层核心功能。

5. Apache

Apache源于NCSAhttpd服务器，经过多次修改，成为世界上最流行的Web服务器软件之一。Apache是自由软件，所以不断有人来为它开发新的功能、新的特性、修改原来的缺陷。Apache的特点是简单、速度快、性能稳定，并可做代理服务器来使用。本来它只用于小型或试验Internet网络，后来逐步扩充到各种Unix系统中，尤其对Linux的支持相当完美。

Apache是以进程为基础的结构，进程要比线程消耗更多的系统开支，不太适合于多处理器环境，因此，在一个Apache Web站点扩容时，通常是增加服务器或扩充群集节点而不是增加处理器。到目前为止Apache仍然是世界上用的最多的Web服务器，世界上很多著名的网站都是Apache的产物，它的成功之处主要在于它的源代码开放、有一支开放的开发队伍、支持跨平台的应用（可以运行在几乎所有的Unix、Windows、Linux系统平台上）以及它的可移植性等方面。

6. IIS

Microsoft的Web服务器产品为InternetInformation Server(IIS)， IIS是允许在公共Intranet或Internet上发布信息的Web服务器。IIS是目前最流行的Web服务器产品之一，很多著名的网站都是建立在IIS的平台上。IIS提供了一个图形界面的管理工具，称为 Internet服务管理器，可用于监视配置和控制Internet服务。

IIS是一种Web服务组件，其中包括Web服务器、FTP服务器、NNTP服务器和SMTP服务器，分别用于网页浏览、文件传输、新闻服务和邮件发送等方面，它使得在网络(包括互联网和局域网)上发布信息成了一件很容易的事。它提供ISAPI(IntranetServer API)作为扩展Web服务器功能的编程接口；同时它还提供一个Internet数据库连接器，可以实现对数据库的查询和更新。

（ASP、.net开发的程序一般只能在IIS上运行。）

以上服务器：Tomcat、jboss、 Apache属于开源的软件，同时可以免费使用，IIS是由微软Windows操作系统捆绑的软件，虽然代码没有开源，也属于免费的。Weblogic(BEA公司)和WebSphere（IBM）是属于商业大型应用的软件，如果客户需求上需要、且预算充分的话可以考虑的。

常用的web服务器软件有哪些

1.IIS

IIS是英文Internet Information Server的缩写，译成中文就是"Internet信息服务"的意思。它是微软公司主推的服务器，最新的版本是Windows2008里面包含的IIS 7，IIS与Window Server完全集成在一起，因而用户能够利用Windows Server和NTFS（NT File System，NT的文件系统）内置的安全特性，建立强大，灵活而安全的Internet和Intranet站点。

2.ApacheApache

ApacheApache在世界上的排名是第一的，它可以运行在几乎所有广泛使用的计算机平台上。Apache源于NCSAhttpd服务器，经过多次修改，不仅简单、速度快、而且性能稳定，还可以用来做代理服务器。

3.Nginx

Nginx不仅是一个小巧且高效的HTTP服务器，也可以做一个高效的负载均衡反向代理，通过它接受用户的请求并分发到多个Mongrel进程可以极大提高Rails应用的并发能力。

4.Zeus

Zeus是一个运行于Unix下的非常优秀的Web Server，据说性能超过Apache，是效率最高的Web Server之一。

5.Sun

Sun的Java系统Web服务器也就是以前的Sun ONE Web Server。主要出现在那些运行Sun的Solaris操作系统的关键任务级Web服务器上。它最新的版本号是6.1,可以支持x86版本Solaris，Red Hat Linux，HP-UX 11i， IBM AIX，甚至可以支持Windows，但它的大多数用户都选择了SPARC版本的Solaris操作系统。

以下哪些是asp.net支持的文件夹

1. Bin文件夹

Bin文件夹包含应用程序所需的，用于控件、组件或者需要引用的任何其他代码的可部署程序集。该目录中存在的任何.dll文件将自动地链接到应用程序。如果在该文件夹中留有不用的或过期的文件，则可能出现“二义性引用(ambiguous reference)”异常的风险。换句话说，如果两个不同的程序集定义相同的类(相同的命名空间和名称)，则ASP.NET运行库不能决定应该使用哪一个程序集，从而抛出一个异常。在开发时，当我们重新命名一个项目或一个程序集的名称时，这是常见的错误。为了避免这种错误，一定不要在该文件夹中保留任何不必要的程序集，或者至少要从配置文件的<assemblies>节中删除如下代码行：

<add assembly="*"/>

2. App_Browser文件夹

该可选的文件夹包含.browser文件。.browser文件描述浏览器(不管是移动设备浏览器，还是台式机浏览器)的特征和功能。ASP.NET在安装路径下的Config/Browser文件夹中安装了大量.browser文件，这些文件供所有应用程序共享。我们只是把当前应用程序特有的浏览器文件放在App_Browser文件夹下。.browser文件的内容即时动态地进行编译，以便向ASP.NET运行库提供最新的浏览器信息。

让我们简单谈谈拥有一个自定义的.browser文件可能有帮助的场景。设想应用程序使用了一个在某个浏览器下不能有效呈现的控件。在指定的浏览器中显示宿主页面时，可以编写一个.browser文件，迫使ASP.NET使用一个不同的适配器来生成该控件。

<browsers>

<browser id="browserID">

<controlAdapters>

<adapter controlType="Samples.CustomControl"

adapterType="Samples.Adapters.CustomControlAdapter"/>

</controlAdapters>

</browser>

</browsers>

假设browserID与ASP.NET识别的标准浏览器之一相匹配，则上文所示的.browser文件指示在指定的浏览器下使用CustomControlAdapter呈现CustomControl。

3. App_Code文件夹

App_Code文件夹正好在Web应用程序根目录下，其存储所有应当作为应用程序的一部分动态编译的类文件。这些类文件自动链接到应用程序，而不需要在页面中添加任何显式指令或声明来创建依赖性。App_Code文件夹中放置的类文件可以包含任何可识别的ASP.NET组件——自定义控件、辅助类、build提供程序、业务类、自定义提供程序、HTTP处理程序等。

注意在开发时，对App_Code文件夹的更改会导致整个应用程序重新编译。对于大型项目，这可能不受欢迎，而且很耗时。为此，鼓励大家将代码进行模块化处理到不同的类库中，按逻辑上相关的类集合进行组织。应用程序专用的辅助类大多应当放置在App_Code文件夹中。

App_Code文件夹中存放的所有类文件应当使用相同的语言。如果类文件使用两种或多种语言编写，则必须创建特定语言的子目录，以包含用每种语言编写的类。一旦根据语言组织这些类文件，就要在web.config文件中为每个子目录添加一个设置：

<compilation>

<codeSubDirectories>

<add directoryName="VBFolder"/>

</codeSubDirectories>

</compilation>

重要的是，特定语言的子目录应在web.config文件中注册，否则，不管它们属于哪个文件夹，App_Code文件夹下的所有文件将被编译成一个单独的程序集。上述配置脚本描述了这么一种情况，即所有的C#文件都放在App_Code文件夹的根目录下，而把几个 Visual Basic.NET类文件移入VBFolder目录中。如果<codeSubDirectories>节中提到的目录不存在，则会收到一个编译错误提示。

App_Code根文件夹中的文件被编译成App_Code_xxx.dll程序集，其中xxx是随机生成的字符序列。一个给定子目录中的文件将被编译成一个名为App_SubCode_xxx_yyy.dll的动态创建的程序集，其中xxx指示子目录的名称，而yyy是一个随机字符序列。只有在应用程序根目录中的web.config文件中进行了设置，<codeSubDirectories>节才有效。

在App_Code目录或任何其他子目录中放置一个assemblyinfo.cs文件，可以创建一个强命名的程序集。显然，如果该文件夹包含Visual Basic.NET文件，那么将使用assemblyinfo.vb文件。程序集配置文件可以引用一个.snk文件来保存强名称的密钥。

注意给一个程序集设置一个强名称，首先必须获得一个公开/私有密钥对。通过使用强名称(Strong Name)工具(sn.exe)，可以获得这样一个密钥对。强名称工具是我们可以在.NET Framework的安装路径中发现的SDK binary之一。密钥对文件通常有一个.snk扩展名。可以将该文件保存到一个应用程序文件夹中，并在assemblyinfo.cs文件中引用它，如下所示：

[assembly: AssemblyKeyFileAttribute(@"yourKeyPair.snk")]

注意，Visual Basic.NET是在包含Visual Studio Solution的目录中寻找密钥文件，而C#编译器则在包含该binary的目录中寻找密钥文件。据此可知，用此属性调整我们使用的路径，或者把密钥文件放在合适的文件夹中。

在随后发生的任何重新生成中，程序集的名称将发生变化。同时，老的AppDomain请求一结束，就删除老的程序集。

App_Code文件夹并非只能包含类文件。特别是，它可以包含并能自动地处理代表数据架构的XSD文件。把一个XSD文件添加到该文件夹中时，编译器将把它解析成一个有类型的DataSet类，并将它添加到应用程序作用域中。在ASP.NET 1.x中，这一工作由Visual Studio.NET向导，使用一个命令行实用程序(xsd.exe)完成的。

注意使用web.config文件注册一个组件(例如，一个自定义的服务器控件或一个自定义的HTTP处理程序)时，通常要求指定包含该代码的程序集名称。如果该组件定义在App_Code文件夹中，则应该用什么名称来指示程序集？在这种情况下，只是忽略程序集信息，并规定完整的类名即可。如果没有规定任何程序集，则ASP.NET运行库将试图从任何已装载的程序集中装入该类，包括为App_Code文件夹动态创建的程序集。

4. App_Data文件夹

App_Data文件夹应该包含应用程序的本地数据存储。它通常以文件(诸如Microsoft Access或Microsoft SQL Server Express数据库、XML文件、文本文件以及应用程序支持的任何其他文件)形式包含数据存储。该文件夹内容不由ASP.NET处理。该文件夹是ASP.NET提供程序存储自身数据的默认位置。

注意默认ASP.NET帐户被授予对文件夹的完全访问权限。如果碰巧要改变ASP.NET帐户，一定要确保新帐户被授予对该文件夹的读/写访问权。

5. App_GlobalResources文件夹

正如其他应用程序一样，ASP.NET应用程序也可以使用资源，而且通常应该使用资源。资源是隔离应用程序用户界面的可局部化部分的一种有效方法。一般而言，资源是与程序相关的不可执行的文本。典型的资源有图像、图标、文本和附属文件，但是任何可序列化的对象也可以被看作资源。应用程序资源存储在应用程序的外部，这样就能在不影响和重新编译应用程序本身的情况下重新编译和替换它们。

ASP.NET应用程序需要有一个主要程序集来保存应用程序默认的或中性的资源。此外，还要部署许多附属程序集，它们中各自包含我们需要支持的某种文化的本地化资源。在ASP.NET 1.x中，编译一个程序集内的资源有点麻烦。需要手动地将基于XML的资源文件(那些带.res扩展名的资源)编译成.resources二进制文件。这些文件既可以嵌入到一个.NET可执行文件中，也可以编译成附属程序集。使用资源文件生成器实用程序resgen.exe，将文本和基于XML的资源文件转变为.resource文件。资源文件名称遵循baseName.cultureName.resource命名约定，其中baseName通常是应用程序的名称：

resgen.exe ProAspNet20.resx ProAspNet20.it.resources

创建.resource文件以后，应当把它嵌入到一个程序集中，甚至可以作为一个资源容器来使用。要把一个资源文件嵌入到一个附属程序集中，可以使用程序集连接器工具(al.exe)。在命令行上，指出程序集所使用的文化(如下面示例中的it，它代表意大利)和名称。

al/out:ProAspNet20.resources.dll/c:it/embed:ProAspNet20.it.resources

在编译附属程序集之后，它们将有相同的名称。将它们部署到不同的子目录中，分别按文化命名。

幸运的是，对于ASP.NET 2.0，附属程序集的时代已经一去不复返了。更准确地说，附属程序集仍然存在，但是由于App_GlobalResources保留文件夹，对开发人员来说它们已经成为过去的事情。

该文件夹中的任何定位的.resx文件自动地被编译成附属程序集。.resx文件的名称包含文化信息，以帮助ASP.NET运行库环境的程序集生成。如下文件，resources.resx, resources.it.resx, resources.fr.resx，生成中性程序集以及适合于意大利(Italian)和法国(French)文化的附属程序集。如果没有要求特定文化，则中性程序集是默认的文化资源。

OK，关于支持asp的web服务器有和不能作为web服务器的是的内容到此结束了，希望对大家有所帮助。