c# 调用EXCEL在VS上能正常运行，部署在IIS上不能实现，在VS中运行页面和发布之后在IIS中运行的区别

发现一篇文章，很好，解决了这个问题；感谢原博主！特此做个笔记。

地址：http://www.cnblogs.com/zhongxinWang/p/3275154.html

发布在IIS上的Web程序，调用服务器的COM组件

　　场景大致是这样的，在工厂中分布着许多的PDA点，这些PDA点都要进行实时的扫描--打印操作。实现方法是采用网络打印机，然后服务器安装驱动，管理着所有的打印机。然后服务器，发布一个WebService，给每个PDA上的程序进行调用，PDA在要进行打印的时候，就掉用这个服务，传递相应参数，给服务器，然后由服务器去选择打印机(当然是PDA想要的那个打印机了)。

　　另外服务器选择打印机进行打印的时候，要调用BarTender进行打印，这个时候，发布在IIS上的Web程序访问COM会出现错误，就像网上流传的访问Excel、Word之类的一样。

　　感谢下面的博主。

　　转：http://blog.csdn.net/yangtze_nancy/article/details/5933634

　　问题描述：最近做一个web应用程序需要操作Excel文件，在开发环境下程序测试正常，部署到IIS后程序操作Excel文件，IIS报错，错误出现在创建Excel进程的语句，如下：

Application myExcelApp = new ApplicationClass();

　　IIS提示信息如下：检索 COM 类工厂中 CLSID 为 {00024500-0000-0000-C000-000000000046} 的组件时失败，原因是出现以下错误: 80070005。

　　异常详细信息:  ASP.NET 未被授权访问所请求的资源。请考虑授予 ASP.NET 请求标识访问此资源的权限。ASP.NET 有一个在应用程序没有模拟时使用的基进程标识(通常，在 IIS 5 上为 {MACHINE}/ASPNET，在 IIS 6 上为网络服务)。如果应用程序正在通过 <identity impersonate="true"/> 模拟，则标识将为匿名用户(通常为IUSR_MACHINENAME)或经过身份验证的请求用户。

问题分析：

在异常详细信息里提到“模拟”,“network  service用户”和“匿名用户”，那就首先分析一下这些概念含义。

（一）   Web.Config配置

1、身份模拟（identity impersonate），这是很关键的一句，表示web应用将为每一个请求进行客户端模拟，就是使用一个指定的账户身份访问web应用。

在不进行客户端模拟设置时，asp.net程序调用excel组件时使用的是network service用户（在xp和2000中，使用的是aspnet用户）使用设置<identity impersonate="true"/>进行客户端模拟时，默认使用的是IUSR_MACHINENAME用户，但该用户没有调用excel组件的权限。设置客户端模拟还可以使用指定的用户，将会以此用户的身份访问web应用，但是要注意的是：由于asp.net的限制，该用户的密码不能为空。如下所示：

<identity impersonate="true" userName="服务器上系统用户名" password="用户密码"/>

2、身份验证（authentication）, 通过 <authentication> 节可以配置 ASP.NET 使用的 安全身份验证模式，以标识传入的用户。Mode选择Windows，表示使用Windows集成的身份验证模式。

<authentication mode="Windows"/>

实际上以上两处配置与IIS的“目录安全性”配置相对应，若在IIS中已做配置后，Web.config里可不再设置，通常创建IIS虚拟目录时，默认会配置使用客户端模拟，模拟身份是“匿名用户”即IUSR_MACHINENAME（在xp和2000中，使用的是aspnet用户）。如下图所示：

（二）   Network Service系统用户

在安装IIS后，系统上会有三个值得我们关注的用户,分别是aspnet、iusr_machinename、iwam_machinename，如下图所示：

在IIS 5中，asp.net应用程序通过ASPNET用户访问，在IIS 6/7中，ASPNET账户被替换成Network Service，asp.net 应用程序需要以“Network Service” 进程标识运行来访问，这个进程标识对应两个账户：IUSR_MACHINENAME和IWAM_MACHINENAME，其作用见上图。而其ASP.NET程序能访问的资源都是受Network Service限制的，这个账户能访问什么资源，ASP.NET程序才能访问资源。

Network Service账户只拥有本机部分权限，它能够以计算机的名义访问网络资源，还有认证用户有权限访问的资源。

综上所述，我们只用在IIS里使用“匿名用户”即以“network service”进程标识就可以访问web应用，无需再配置web.config文件。但是无法创建Excel实例，说明network service进程标识的权限不够，如何给他授权在服务器上创建Excel实例呢？

（三）  DCOM组件配置

在服务器上操作excel要调用com组件，因此对network service的授权需要配置excel应用程序com组件。

1、 打开Excel应用程序COM组件

方法：在"开始"->"运行"中输入dcomcnfg.exe启动"组件服务"； 依次双击"组件服务"->"计算机"->"我的电脑"->"DCOM配置"； 在"DCOM配置"中找到"Microsoft Excel 应用程序",在它上面点击右键,然后点击"属性",弹出"Microsoft Excel 应用程序属性"对话框。如下图所示：

2、 配置EXCEL相关COM组件

需要注意的是在笔者的服务器上Excel相关的com组件有2个，分别是：Microsoft Excel应用程序和Microsoft office Excel 2007工作薄，必须同时对这两个com组件做相同的配置，否则仍然会出现无法创建Excel实例的现象。

配置方法：

“常规”选项卡中“身份验证级别”选择“默认”；

“安全”选项卡中，启动和激活”、“访问权限”和“配置权限”全部选择“自定义”，添加“network service”用户并赋予最大权限。

“标识”选项卡中，选择“启动用户”，最后点击确认。

如下图所示：

经过这样配置以后，web应用能够成功访问，Excel实例也能够正常创建，COM类工厂错误80070005成功解决！

这里我做了一个实验，若“标识”中选择的是“交互式用户”，则web应用能够成功访问，但不能创建Excel实例，此时COM类工厂报告另外一个错误8000401a，如下图所示：

这里有必要说一下“交互式用户”与“启动用户”的区别：

交互式用户 (The interactive user)	这是推荐的选项, 以当前登录到系统的用户确定对象的身份(当前必须有用户登录到系统, 如果用户注销那么对象也会被销毁)
启动用户 (The launching user)	以调用的客户端的用户确定对象的身份, 一个缺点就是这个对象不能再进行远程调用

为什么选择“交互式用户”会出现8000401a错误呢? 原因是使用的身份不对，因为此时我使用administrator登录服务器，所以交互式用户就是administrator，如果选择的是“启动用户”，将以调用的客户端的用户确定对象身份，客户端所使用的是“匿名账户IUSR_MACHINENAME”，调用它的是network service进程标识。我们在前面配置DCOM时已经赋予network service相应权限，但没有给administrator授权，那是不是给administrator授权后选择交互式用户就可以创建excel实例了呢？

应此，我按这个思路做了五组实验：

【试验一】

DCOM设置使用“交互式用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”、“访问权限”和“配置权限”全部选择自定义，并且都加入administrator用户（因为当前使用的登录用户是administrator）并赋予最大权限，IIS目录安全性中按默认设置

实验结果：能正常访问web应用，但不能操作excel，报 COM 类工厂错误代码 8000401a

 

【实验二】

DCOM设置使用“交互式用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”、“访问权限”和“配置权限”全部选择自定义，并且都加入administrator用户（因为当前使用的登录用户是administrator）并赋予最大权限，IIS目录安全性中按默认设置，但web.config文件中设置使用administrator身份模拟

实验结果：能正常访问web应用，但不能操作excel，报 COM 类工厂错误代码 8000401a

 

【实验三】

DCOM设置使用“启动用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”、“访问权限”和“配置权限”全部选择自定义，并且都加入administrator用户（因为当前使用的登录用户是administrator）并赋予最大权限，IIS目录安全性中按默认设置，但web.config文件中设置使用administrator身份模拟

实验结果：能正常访问web应用，能正常创建excel实例

【实验四】

DCOM设置使用“启动用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”、“访问权限”和“配置权限”全部选择自定义，并且都加入administrator用户（因为当前使用的登录用户是administrator）并赋予最大权限，IIS目录安全性中按默认设置，但web.config文件中设置使用IUSR_MACHINENAME身份模拟

实验结果：能正常访问web应用，但不能操作excel，报 COM 类工厂错误代码 8000401a

【实验五】

DCOM设置使用“启动用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”、“访问权限”和“配置权限”全部选择自定义，并且都加入administrator用户（因为当前使用的登录用户是administrator）并赋予最大权限，IIS目录安全性中按默认设置，但web.config文件中不使用身份模拟

实验结果：不能正常访问web应用，也不能操作excel

上面五个实验说明：在web.config中设置“身份模拟”只对DCOM中的 “启动用户”才有效，且欲操作Excel还必须在DCOM中赋予“身份模拟”的用户最大权限。

为求彻底弄清楚问题的本质，我又做了几组实验：

【试验一】

DCOM设置使用“交互式用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”、“访问权限”和“配置权限”全部选择“默认”，IIS目录安全性中按默认设置，web.config文件中设置使用IUSR_MACHINENAME身份模拟

实验结果：不能正常访问web应用，也不能操作excel

 

【试验二】

DCOM设置使用“交互式用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”、“访问权限”和“配置权限”全部选择自定义，并且都加入network service用户（此时已删除administrator用户）并赋予最大权限，IIS目录安全性中按默认设置，web.config文件中设置使用IUSR_MACHINENAME身份模拟

实验结果：不能正常访问web应用，也不能操作excel

 

【试验三】

DCOM设置使用“启动用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”、“访问权限”和“配置权限”全部选择“默认”，IIS目录安全性中按默认设置，但web.config文件中设置使用IUSR_MACHINENAME身份模拟

实验结果：不能正常访问web应用，也不能操作excel

 

【试验四】

DCOM设置使用“启动用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”、“访问权限”和“配置权限”全部选择自定义，并且都加入network service用户（此时已删除administrator用户）并赋予最大权限，IIS目录安全性中按默认设置， web.config文件不使用身份模拟配置

实验结果：能正常访问web应用，能正常创建excel实例

 

【试验五】

DCOM设置使用“启动用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”、“访问权限”和“配置权限”全部选择自定义，并且都加入network service用户（此时已删除administrator用户）并赋予最大权限，IIS目录安全性中按默认设置，但web.config文件中设置使用身份模拟，形式<identity impersonate="true" />或者<identityimpersonate="true" userName="IUSR_ZZUDEV01-VM2" password="密码"/>

实验结果：能正常访问web应用，但访问excel文件被拒绝

 

【试验六】

DCOM设置使用“启动用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”中选择自定义并加入administrator用户和network service用户并赋予最大权限， “访问权限”选择自定义并加入network service用户并赋予最大权限， “配置权限”中选择自定义并加入administrator用户和network service用户并赋予最大权限， IIS的“目录安全性”中按默认设置，但web.config文件中设置使用身份模拟，形式<identity impersonate="true" />或者<identity impersonate="true" userName="IUSR_ZZUDEV01-VM2" password="密码"/>

实验结果：能正常访问web应用，但访问excel文件被拒绝

 

【试验七】

DCOM设置使用“启动用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”中选择自定义并加入administrator用户和network service用户并赋予最大权限， “访问权限”中选择“使用默认值”，即两个用户都不加， “配置权限”中选择自定义并加入administrator用户和network service用户并赋予最大权限， IIS的“目录安全性”中按默认设置，但web.config文件中设置使用身份模拟，形式<identity impersonate="true" />或者<identityimpersonate="true" userName="IUSR_ZZUDEV01-VM2" password="密码"/>

实验结果：能正常访问web应用，也能访问excel文件，但无法创建excel实例，报com类工厂错80070005

 

【试验八】

DCOM设置使用“启动用户”后，身份验证级别选择“默认”，安全选项卡中“启动和激活”中选择自定义并加入administrator用户和network service用户并赋予最大权限， “访问权限”中选择“使用默认值”，即两个用户都不加， “配置权限”中选择自定义并加入administrator用户和network service用户并赋予最大权限， IIS的“目录安全性”中按默认设置，但web.config文件中设置使用administrator身份模拟，即<identity impersonate="true"userName="administrator" password="密码"/>

实验结果：能正常访问web应用，能访问excel文件，能正常创建excel实例

 

经过以上又进行的八组实验说明，在IIS上部署操作Excel的web应用，需要涉及3方面的权限：第一个是访问web应用的权限，第二个是访问excel的权限，第三个是操作excel的权限。

使用“身份模拟”仅能达到访问web应用的效果，还不能具有第二、第三的权限，要访问、操作Excel必须配置DCOM组件，并选择使用“启动用户”。IIS 6默认使用network service进程标识去调用默认的“匿名账户IUSR_MACHINENAME”来用访问web应用，此时操作Excel的“启动用户”应该是network service进程标识，但注意不能将其具体到IUSR_MACHINENAME和IWAM_MACHINENAME用户，通过实验六可以也看出，在DCOM中的“启动和激活”与“访问权限”均配置添加network service用户，web.config文件中使用具体的IUSR_MACHINENAME身份模拟访问Excel文件被拒绝，说明默认匿名账户只有访问web应用的权限，而不具有访问Excel和操作Excel的权限。

访问web应用，可以使用任何身份，IIS 6默认使用 IUSR_MACHINENAME用户，当然也可以在web.config文件中或者IIS 6的“目录安全性”中设置其他“身份模拟”。IUSR_MACHINENAME用户不具有访问Excel和操作Excel的权限，而只有Network Service具有访问和操作Excel的权限。当DCOM中不配置“访问权限”时，web.config中配置的“身份模拟”就充当两种角色，一种是访问web应用的角色，另一种是访问Excel的角色，若在DCOM中给“身份模拟”的用户授予“启动和激活”的权限，则该用户就具有了第三种角色，操作Excel。

最后，在补充一点：IIS的“目录安全性”与web.config文件的“identity impersonate”进行“身份模拟”时优先级的问题

根据实验个人判断，web.config的“身份模拟”优先级较高，但IIS“目录安全性”中的身份模拟为必有项（可根据情况选择使用“匿名用户访问”或者“经身份验证的用户访问”）。当两者同时设置了不同的“身份模拟”时，将以web.config中的“身份模拟”访问web应用。