WCF集成COM+应用程序遇到的问题

本文转载：http://www.cnblogs.com/Charles2008/archive/2010/06/24/1764510.html

最近为培训WCF做了一个演示DEMO，关于WCF集成COM+应用程序时候遇到一个问题：SvcConfigEditor.exe工具不让我集成COM+应用程序,出现的情况如下图所示：

代码如下：

代码 
public interface IOpeate
 {
         int Add(int a, int b);
         string SayHello(string msg);
 }
 public class Opeate:System.EnterpriseServices.ServicedComponent, COMPlusTest.IOpeate
 {
         public int Add(int a, int b)
         {
             return a + b;
         }
         public string SayHello(string msg)
         {
             Console.WriteLine("Hello,{0}",msg);
             return "OK";
         }
 }
 

复制代码

设置如下：

[assembly: ComVisible(true)] [assembly:AssemblyKeyFile(@"C:\Charles2008\COMPlusTest\COMPlusTest\bin\Debug\test.snk")]

复制代码

OK，编译项目，生成COMPlusTest.dll文件。

注册成COM+组件到组件管理器:Regsvcs命令

Regsvcs COMPlusTest.dll，界面如下：

Ok,打开组件管理器：运行输入命令：dcomcnfg打开

OK,组件管理器中已经有了新加的组件COMPlusTest,表示已经注册成功,但是通过SVCConfigEditor.exe工具不能与COM+组件进行集成。

反复试了好多次，卸载了重新安装都只是在组件管理器中成功的注册，但都不能用SvcConfigEditro.exe工具把新添加的COM+应用程序集成。

解决方案：

通过在Internet上不断的寻找解决方案，最后终于在Microsoft的技术资源库中终于找到了：

COM+集成：COM+应用程序的接口作为WCF(Windows Communication Foundation)公开服务的话,需要将程序集添加到全局程序集缓存(GAC)中。

如:输入gacutil.exe /i COMPlusTest.dll (/i表示安装)

卸载的话同理：Gacutil.exe /u COMPlusTest

OK,只有在GAC中注册了，那么通过svcConfigEditor.exe才能把COM+应用程序集成WCF Service.

唉，终于把这个文件解决了。

另外补充：

一般来说，将程序集(dll)安装到GAC中有以下两种方法：

1.手动将要安装部署的dll文件拖至<System Drive>:\Windows\Assembly文件夹下

2.使用gacutil.exe工具安装gacutil -i "dll文件全路径"。

如在命令行输入：gacutil -i C:\Charles2008\COMPlusTest.dll

GAC的概念：

如果一个Assembly要被多个应用程序访问，那么他就必须放在一个CLR已确认的目录下，并且CLR在探测到有对该Assembly的引用时，它必须能自动到目录下去寻找这个程序集。这个已确知的目录称为GAC(Global Assembly Cache)。就是全局程序集缓存。它一般位于厦门的目录下：

<System Drive>:\Windows\Assembly\GAC

GAC的左右就是提供给CLR一个已知的确定的目录去寻找引用的程序集。

GAC的内部结构

GAC是一个特殊的结构化的目录，用Windows Explorer浏览器你会以为它只是一个包含很多程序集的普通目录。其实不是这样的，在命令行下查看，你会发现它实际上包含很多子目录，子目录的名字和程序集的名称是相同的，但他们都不是实际的程序集，实际的程序集位于程序集名对应的目录下。

因为GAC包含很多子目录，这些子目录是用一种算法来产生的，我们最好不要手动将程序集拷贝到GAC中，相反，我们应使用工具来完成这样的工作。因为这些工具知道GAC的内部结构。

我们知道.NET Framework的GAC(global Assembly Cache)其实是一个特殊的目录，如下图：

但是它的内部结构是什么结构呢？

很奇怪吧，两个图看到的结构不一样，其实第一幅图只是一个Windows Explorer特殊的呈现方式。第二幅图才是真正的内部结构。

比如进入GAC_MSIL\System子目录，我们会发现其中又有很多子目录。

但是这里的只有一个目录表示只有一个版本的System程序集被安装。实际的程序集保存在每一个对应的目录下。目录的名称以下划线的形式分割为： “(Version)_(Culture)_(PublicToken)”。

System的语言文化为neutral，就表示为2.0.0.0__b77a5c561934e089.表示的意义是：“System Version=2.0.0.0,Culture=neutral,PublicKeyToken=b77a5c561934e089”。如果语言的文化是en，则表示:2.0.0.0__en_b77a5c561934e089

OK，还有一个问题：CLR是怎么知道一个程序集需要引用另外的程序集呢？

其实一个Assembly不只包含代码，还包含其他一些东西，如MANIFEST.里面就有有关引用的信息。CLR找到引用的DLL名称后是怎么去寻找的呢？

它一般情况下遵循下面的原则：

1.如果程序集有强名称，在首先在全局程序集缓(GAC)中查找程序集----->GAC(应该是先找平台相关的，例如:GAC_32,GAC_64，然后找去找GAC_MSIL)。

2.程序集的根目录

3.如果上面的路径无法找到，则继续查找当前程序是否设置了特殊的私有路径。

代码 
<?xml version="1.0" encoding="utf-8" ?>
 <configuration>
   <runtime>
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
       <probing privatePath="CharlesRoot;CharlesCore;CharlesModule;CharlesPDA"/>
     </assemblyBinding>
   </runtime>
 </configuration>
 

复制代码

那如果上面都找不到，就提示发生错误。以上的过程是发生在运行期间的。那么在编译的时候，顺序有是怎么样的？

1.程序集的根目录

2.CSC程序的目录

3.GAC

那如果也无法找到，则就会出现编译时候的错误。