TL; DR;

Question

我正在研究一个免费的私有注册WinSxS的配置，其中包含简单的程序集清单文件，在部署和运行时将Delphi可执行文件（COM客户端）和.NET（C＃）COM可见DLL组合在一起。

我已经研究过MSDN "Interoperating with Unmanaged Code"提供的文档，特别是关于"COM Callable Wrapper"和"How to: Configure .NET Framework-Based COM Components for Registration-Free Activation"的部分。

经过一个多星期的研究并在文件不足的情况下（重新）指导，我决定在这里提出我的第一个问题。

计划的部署结构如下所示：

./install-root
├───ProgramSuite1
│   ├───bin
│   │       DelphiNativeCOMClient1.exe
│   │       DelphiNativeCOMClient1.exe.config
│   │       DelphiNativeCOMClient2.exe
│   │       DelphiNativeCOMClient2.exe.config
│   |       ...
│   │
│   └───data
│           ...
├───ProgramSuite2
│   ├───bin
│   │       DelphiNativeCOMClient3.exe
│   │       DelphiNativeCOMClient3.exe.config
│   │       DelphiNativeCOMClient4.exe
│   │       DelphiNativeCOMClient4.exe.config
│   |       ...
│   │
│   └───data
│           ...
└───SharedLibs
    ├───MyCompany.Libs.Set1
    │       MyCompany.Libs.Set1.manifest
    │       SomeManagedCOMServerA.dll
    │       SomeNativeCOMServerB.dll
    │       SomeNativeCOMServerC.dll
    │
    └───MyCompany.Libs.Set2
            MyCompany.Libs.Set2.manifest
            SomeManagedCOMServerB.dll
            SomeNativeCOMServerX.dll
            SomeManagedCOMServerA.dll

这里是关于Delphi本机可执行文件和C＃.NET COM服务器DLL实现的实现的简短草图（我遗漏了原生COM服务器的示例，因为这些东西已经运行良好并且已经完成了问题）我主要关注"Registration-Free Activation of COM Components: A Walkthrough"提供的内容。主要区别在于我使用Delphi而不是C，C ++或旧VB作为原生客户端。

`TestDllConsoleApp.exe`

`TestDllConsoleApp.dpr`

program TestDllConsoleApp;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  DllTests.Common,
  WinApi.ActiveX,
  WinApi.Windows,
  // These were generated using the tlbimplib tool
  CSharpCOMDll_TLB in 'CSharpCOMDll_TLB.pas',
  mscorlib_TLB in 'mscorlib_TLB.pas';

var
    comInterface1 : ICOMInterface1;
    comInterface2 : ICOMInterface2;
    intf1CoClass : _COMImplClass1; 
    intf2CoClass : _COMImplClass2;
    res : HRESULT;
    coInitializeRes : integer;
begin
    //Initialize COM
    coInitializeRes := CoInitializeEx(nil, COINIT_APARTMENTTHREADED);
    if (coInitializeRes <> S_OK) and (coInitializeRes <> S_FALSE) then begin
        System.ExitCode := 1;
        Exit(); // GUARD
    end;
    try
        try
            intf1CoClass := CoCOMImplClass1.Create();
            res := intf1CoClass.QueryInterface(IID_ICOMInterface1,comInterface1);
            System.WriteLn(comInterface1.GetModuleName());

            intf2CoClass := CoCOMImplClass2.Create();
            res := intf2CoClass.QueryInterface(IID_ICOMInterface2,comInterface2);
            System.WriteLn(comInterface2.GetModuleName());
        except
        on E: Exception do
            Writeln(E.ClassName, ': ', E.Message);
        end;
    finally
        //Uninitialize COM
        CoUninitialize();
    end;
end.

`TestDllConsoleApp.manifest`

（嵌入资源ID 1）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"> 
    <assemblyIdentity name="MyCompany.Software.Application" processorArchitecture="x86" version="1.0.0.0" type="win32" />
    <description>A native COM client application.</description>
    <asmv3:trustInfo>
        <asmv3:security>
            <asmv3:requestedPrivileges>
                <asmv3:requestedExecutionLevel level="asInvoker" uiAccess="false" />
            </asmv3:requestedPrivileges>
        </asmv3:security>
    </asmv3:trustInfo>
    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
        <application>
            <!-- Windows 10 and Windows Server 2016 --> 
            <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
            <!-- Windows 8.1 and Windows Server 2012 R2 -->
            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
            <!--  Windows 8 and Windows Server 2012 -->
            <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
            <!-- Windows 7 and Windows Server 2008 R2 -->
            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
            <!-- Windows Vista and Windows Server 2008 -->
            <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />
        </application>
    </compatibility>
    <dependency>
        <dependentAssembly>
            <assemblyIdentity type="win32" name="MyCompany.Libs.Set1" version="1.0.0.0" processorArchitecture="x86" />
        </dependentAssembly>
    </dependency>
</assembly>

`TestDllConsoleApp.exe.config`

（部署在与可执行文件相同的文件位置）

<configuration>  
   <runtime>  
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">  
         <probing privatePath="..\..\SharedLibs"/>  
      </assemblyBinding>  
   </runtime>  
</configuration>

`CSharpCOMDll.dll`

（将部署在SharedLibs\MyCompany.Libs.Set1目录）

`Assemblyinfo.cs`

#region Using directives
using System;
using System.Reflection;
using System.Runtime.InteropServices;

#endregion
[assembly: AssemblyTitle ("CSharpCOMDll")]
[assembly: AssemblyProduct ("CSharpCOMDll")]
[assembly: AssemblyCopyright ("Copyright 2018")]
[assembly: ComVisible (true)]
[assembly: AssemblyVersion ("1.0.0.0")]
[assembly: Guid ("045d53ab-a9e4-4036-a21b-4fe0cf433065")]

COMImplClass1.cs

// Using namespaces ...
namespace CSharpCOMDll
{
    [Guid("6BDAF8DD-B0CF-4CBE-90F5-EA208D5A2BB0")]
    public interface ICOMInterface1  
    {
        string GetModuleName();
    }

    [Guid("4CD39F25-0EB9-4CD0-9B4C-6F5DB5C14805")]
    public class COMImplClass1 : ICOMInterface1
    {
        public string GetModuleName() 
        {
            return typeof(COMImplClass1).Module.FullyQualifiedName;
        }
    }
}

COMImplClass2.cs

 // Using namespaces ...
namespace CSharpCOMDll
{

    [Guid("BE69E9C7-1B37-4CA8-A3C1-10BFA9230940")]
    public interface ICOMInterface2  
    {
        string GetModuleName();
    }

    [Guid("067E5980-0C46-49C7-A8F0-E830877FB29C")]
    public class COMImplClass2 : ICOMInterface2
    {
        public string GetModuleName() 
        {
            return typeof(COMImplClass1).Module.FullyQualifiedName;
        }
    }
}

`CSharpCOMDll.manifest`

（嵌入到资源ID为2的DLL中）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" 
  manifestVersion="1.0">
    <assemblyIdentity
                type="win32"
                processorArchitecture="x86"
                name="CSharpCOMDll"
                version="1.0.0.0" />
    <clrClass
                clsid="{4CD39F25-0EB9-4CD0-9B4C-6F5DB5C14805}"
                progid="CSharpCOMDll.COMImplClass1"
                threadingModel="Both"
                name="CSharpCOMDll.COMImplClass1" 
                runtimeVersion="v4.0.30319">
    </clrClass>
    <clrClass
                clsid="{067E5980-0C46-49C7-A8F0-E830877FB29C}"
                progid="CSharpCOMDll.COMImplClass2"
                threadingModel="Both"
                name="CSharpCOMDll.COMImplClass2" 
                runtimeVersion="v4.0.30319">
    </clrClass>
</assembly>

最后，程序集清单已从TestDllConsoleApp.manifest dependency条目解析：

`MyCompany.Libs.Set1.manifest`

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    <assemblyIdentity type="win32" name="MyCompany.Libs.Set1" version="1.0.0.0" processorArchitecture="x86" />
    <file name="CSharpCOMDll.dll"> 
        <comClass
            clsid="{4CD39F25-0EB9-4CD0-9B4C-6F5DB5C14805}"
            threadingModel="Both"
            />
        <comClass
            clsid="{067E5980-0C46-49C7-A8F0-E830877FB29C}"
            threadingModel="Both"
            />
        <comInterfaceProxyStub
            name="ICOMInterface1"
            iid="{6BDAF8DD-B0CF-4CBE-90F5-EA208D5A2BB0}"
            proxyStubClsid32="????"
        />
        <comInterfaceProxyStub
            name="ICOMInterface2"
            iid="{BE69E9C7-1B37-4CA8-A3C1-10BFA9230940}"
            proxyStubClsid32="????"
        />
    </file>
</assembly>

似乎我已经到了中途，但仍无法诊断实际问题。

现在有两种失败的变种（请注意，在可执行文件旁边部署托管COM服务器DLL而不是引用已解析的清单目录，只是按照预期正常工作）：

我完全删除了全局清单中的proxyStubClsid32属性：
- 启动可执行文件最终会出现异常 EOleSysError: Error in dll, clsid = {4CD39F25-0EB9-4CD0-9B4C-6F5DB5C14805}
- 调试异常会导致HRESULT值
```
 Error in the DLL (Exception from HRESULT: 0x800401F9 (CO_E_ERRORINDLL))
```
我在全局清单中提供了proxyStubClsid32属性：
- 我不确定该属性实际上是否需要GUID 正如它在文档中提到的那样，它自然似乎是一个相应的同类ID＆＃34; CLSID元素comClass属性中提到的{clsid}。
- 我或者试图从生成的,pas文件中提供LIBID GUID。
这两种变体都给我留下了一个无法用sxstrace工具¹追踪的无用错误：
```
 ...
 INFORMATION: Manifestdatei ".\install-root\SharedLibs\MyCompany.Libs.Set1\MyCompany.Libs.Set1.MANIFEST" wird analysiert.
    INFORMATION: Die Manifestsdefinitionsidentität ist ",processorArchitecture="x86",type="win32",version="1.0.0.0"".
 FEHLER: Bei der Generierung des Aktivierungskontextes ist ein Fehler aufgetreten.
 Beendet die Generierung des Aktivierungskontextes.
```
请注意，没有任何简洁的错误/信息消息，如
```
  ... cannot resolve assembly XY ...
```
在激活上下文生成搞砸之前
。有大量的参考资料表明这种特殊的错误此外，无处不在的提及缺少 Visual C ++可再发行框架在这里并没有帮助。我是从德尔福打来的，那是与众不同的。
另一种尝试明确地引用CSharpCOMDll.dll（可执行清单中的另一个依赖项），并将其放入SharedLibs得到一个成功创建的激活上下文 ，但失败的例外情况略有不同
```
EOleSysError: Cannot find file, clsid = {4CD39F25-0EB9-4CD0-9B4C-6F5DB5C14805}
```

这里有没有人知道如何做我想要的直截了当，或者除了sxstrace之外还可以做些什么来更深入地诊断问题。

我几乎可以肯定必须提供像这样的部署。

TL; DR;

是否可以提供如上所述的部署结构，并在引用的可执行文件位置之外维护某些.NET COM服务器DLL？

更新

今天进一步研究，我意识到（尽管术语非常相似），使用私有SxS解析 ActivationContext 并解析用于COM可调用包装器实例化的.NET DLL的位置是两个完全不同和分离的机制。我大部分时间都是从这两篇文章中得到的，还有一些Jufeng Zhang's精彩而深入地解释博客文章：

定位未注册的.NET程序集（托管COM服务器DLL）的问题是，这只会发生在应用程序部署目录及其下方。

使用任何方法，例如在配置<codebase>文件所在目录之外的配置<probing>部分中指定<runtime>或.config元素，就不会这样做。工作。

我验证了使用Sysinternals Process Monitor和Fusion日志查看器工具²。

我没有将其作为最终答案发布，因为我将尝试下一步以某种方式欺骗.NET机制来定位托管COM服务器DLL，使用程序集清单或指定依赖项的本机DLL和<probing> / <codebase>元素重定向定位机制。

作为最后的手段（原文！），似乎甚至可以在appDomainManagerAssembly元素下的应用程序配置中提供您自己的自定义appDomainManagerType和<runtime>。

更新II：

我担心我们必须使用来自本机CLR主机的CLR API来管理AppDomain。

需要进一步调查。一个有前途的资源如何做到这一点我在这里找到：

"Customizing the Microsoft .NET Framework Common Language Runtime"

^1） _{请原谅德语错误消息。我手头没有英文版编译器。但谷歌提供的翻译应该运作良好。}

^2） _{所以关于更好的诊断问题的工具的问题可以被认为已经解决了。}

Answer 1

是否可以提供如上所述的部署结构，并在引用的可执行文件位置之外维护某些.NET COM服务器DLL？

绝对不可能（！）来解析为var waPlugin = createjs.Sound.activePlugin; var context = waPlugin.context; var yourNode = context.createConvolver(); // set up your convolver node here with your convolution buffer waPlugin.dynamicsCompressorNode.disconnect(); waPlugin.dynamicsCompressorNode.connect(yourNode); yourNode.connect(context.destination);的可执行目录之外的内部CLR托管机制提供的任何程序集。

您可以使用

AppDomain

但<probing privatePath="<some directory below your executable's location>" />`标记对SxS解析（出现在清单<probing>标记下）的工作方式不同，而CLR的机制实例化{em> COM Callable Wrappers 出现在{{ 1}}标签。

它甚至没有记录，但指定

<windows>

用于解析SxS依赖项支持 <runtime> 的相对路径，从您的可执行文件位置起最多3个<windows> <probing privatePath="../<xxx>" /> </windows>父目录级别适用于任何本机COM服务器，而

<xxx>

或

../

将不允许您使用标准Windows .NET机制指定要将实例化为 COM Callable Wrappers的候选项指定位于 AppDomain 主机目录之外的位置的程序集位置（由<runtime> <probing privatePath="../<xxx>" />  </runtime>主持）。
从可执行文件的部署目录中更深入地下载可以正常工作。

拦截CLR探测机制的一种方法（可能是最简单的）是提供自定义<runtime> <codebase href="../<xxx>/xyz.dll" version="1.0.0.0"/>  </runtime>实现并在应用程序配置文件的<appDomainManagerAssembly>和<appDomainManagerType>元素中指定它：

mscoreee.dll

AppDomainManager类的实现应该在.NET程序集中，例如用C＃编写：

 <configuration>
     <runtime>
          <appDomainManagerAssembly value="MyAppDomainMgr" />
          <appDomainManagerType value="MyAppDomainMgr.MyCustomAppDomainMgr, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
     </runtime>
 <configuration>

一旦您的非托管应用程序尝试通过CLR访问某个COM接口（COM Callable Wrapper）（即调用MyAppDomainMgr.MyCustomAppDomainMgr），namespace MyAppDomainMgr { [ComVisible(true)] public class MyCustomAppDomainMgr : AppDomainManager { public MyCustomAppDomainMgr() { } public override void InitializeNewDomain(AppDomainSetup appDomainInfo) { Console.Write("Initialize new domain called: "); Console.WriteLine(AppDomain.CurrentDomain.FriendlyName); InitializationFlags = AppDomainManagerInitializationOptions.RegisterWithHost; // Several ways to control settings of the AppDomainSetup class, // or add a delegate for the AppDomain.CurrentDomain.AssemblyResolve // event. } } }类将被实例化并CoCreateInstance()首先调用函数。

最少侵入性的方式似乎是添加该委托功能：

MyCustomAppDomainMgr

生成的程序集（InitializeNewDomain()）必须放在非托管可执行应用程序下面。

如何提供正确定位.NET Dll作为COM提供程序的私有并排清单？

`TestDllConsoleApp.exe`

`TestDllConsoleApp.dpr`

`TestDllConsoleApp.manifest`

`TestDllConsoleApp.exe.config`

`CSharpCOMDll.dll`

`Assemblyinfo.cs`

COMImplClass1.cs

COMImplClass2.cs

`CSharpCOMDll.manifest`

`MyCompany.Libs.Set1.manifest`

TL; DR;

更新

更新II：

1 个答案: