我在安装过程中遇到了这个错误，

安装程序集 'policy.9.0.Microsoft.VC90.MFC,version="9.0.21022.8",publicKeyToken="1fc8b3b9a1e18e3b", processorArchitecture="x86",type="win32-policy"' 时出错。

我已经广泛搜索了解决方案，有些人遇到了类似的问题，但他们要么没有解决方案，要么他们的解决方案不起作用。有这些组件经验的人知道为什么会这样吗？

有关更多上下文，这是用于 USB 设备固件配置工具的 Windows 安装程序。

提前致谢。

程序集的默认版本存储在哪里？

当我运行 python.exe（2.6 或 2.7）并使用 Process Explorer 检查它时，我看到它加载了最新版本的 msvcr90.dll（我的 PC 上的 9.0.30729.9247）。Python 有一个内部清单，它指定了 msvcr90.dll 的 9.0.21022.8 版本，但仍会加载较新的版本。Python 2.6 有一个 Microsoft.VC90.CRT.manifest 文件，它也指定了 9.0.21022.8，但总是加载较新的版本。

使用进程监视器，我可以在加载 msvcr90.dll 时看到所有其他实例，它们都使用 9.0.30729.9247。

我的电脑必须在某个地方告诉所有这些程序使用较新的版本，但我似乎无法找到在哪里。我的 WinSxS 文件夹中有许多版本的 microsoft.vc90.crt。

如果我无法更改默认版本，有什么方法可以“降级”我的 microsoft.vc90.crt？到看起来更标准的版本 (9.0.30729.6161)

PS。我不知道我的 microsoft.vc90.crt 版本 9.0.30729.9247 来自哪里

我一直在尝试实现以下场景：

应用程序 [C++] 在注册的 COM 类 (CReg/Reg.dll) 上使用 CoCreateInstance

CReg 类在 regfree/SxS COM 类 (CFree/Free.dll) 上使用 CoCreateInstance。

CoCreateInstance 返回 REGDB_E_CLASSNOTREG。

问题似乎与清单无关，因为如果我尝试通过应用程序直接实例化 CFree，则创建对象没有问题。

我已经检查并且上面的场景触发了 CReg 的激活上下文（我已经检查了 sxstrace），甚至 CFree 的清单也已成功加载（！），这应该在正确的 regfree COM 中起作用。如果我更改 CFree 的清单，那么激活上下文会失败（我相信这证明了它在更改之前被正确触发和加载）。

使用已注册的 COM [CReg] 的场景是否无法访问 CFree 对象？如果可能的话，是否有一些特殊的工作才能正确加载它？

编辑

在 Joe 的帮助下，我们发现问题出在 Free.dll 所在的位置。

主要应用程序（例如）在 C:\Proj\App 中，Reg.dll 和 Free.dll 都在 C:\Proj\Libs 中。是否有可能加载与应用程序位于不同位置的 regfree Free.dll？问题是我不能将它放在应用程序目录或应用程序子目录中（它必须在外部位置）。

我尝试在 Reg.dll 项目上使用 ISOLATION_AWARE_ENABLED 预处理器定义，以从 Reg.dll 目录触发激活上下文。来自 Free.dll 的清单已正确加载（sxstrace 记录），但 CoCreateInstance 调用仍返回 REGDB_E_CLASSNOTREG。这篇博客文章指出，这个定义可能是可能的（但没有就此问题给出明确的答案）。

任何人都可以帮助我解决这个问题，或者至少指向可能给我答案的文档，无论是否有可能，从外部位置加载 regfree dll？

我们维护旧版 VB6 应用程序。在版本 X 之前，它是通过注册其所有 COM 依赖项来安装的。从 >X 版本开始，我们开始使用应用程序清单来发布它。

在某些情况下，版本 >X的主 EXE 进程比版本≤X 的终止时间长约 30 秒。（此效果在 Windows 任务管理器中可见）。

只是预感是对清单的更改导致了延迟。应用程序中也有其他变化，但似乎没有一个相关的变化。

注意：它快速终止的场景是它被执行然后立即退出的地方。但是延迟是由某些操作引入的，这些操作通过调用其他一些 VB6 COM DLL 来打开数据文件，使用 DAO 读取一些 MDB 等。对于许多版本的应用程序，这些都没有改变。

相同的情况不会导致版本 ≤X 的延迟。

因此，尚不清楚哪一行代码直接导致延迟发生或不发生。在我可能花费大量时间来追踪它之前，我正在寻找输入来确认或否认这个明显的假设。

有什么方法可以查看正在运行的 Windows 进程的激活上下文？

理想情况下，当我说“查看”时，我的意思是以人类可读的方式检查它，例如查看/确认已加载哪些 DLL 等。

我的想象是某种调试器可能会附加到正在运行的进程，然后显示该信息。但任何类型的工具都可能有用 - 调试器、日志文件，甚至使用激活上下文 API 来检查事物等。

背景：
1、安装windows更新时，windows安装程序会先检查一些.dll文件的版本，可以在winsxs文件夹中找到
2、winsxs文件夹中的目录名是dll不同属性的组合：

amd64_microsoft-windows-wintrust-dll_31bf3856ad364e35_6.1.7601.23468_none_4e2b9c2fc9f33913

问题：
很明显：
amd64表示处理器架构
microsoft-windows-wintrust-dll表示 dll 的名称
6.1.7601.23468表示版本
none表示文化（或语言）

但我不知道是什么“4e2b9c2fc9f33913”是什么意思？我猜这是一个哈希值，但我不知道如何计算它。

我在互联网上找到了一些相关的问题，但所有的答案都没有包括如何计算这个值。有人知道吗？

谢谢。

这个问题与这个问题有点相似，只是有点扭曲： 我可以修改并排汇编搜索顺序吗？

我们有几个不同的软件，用不同的语言制作，它们在运行时会相互通信。为了实现这一点，我们制作了使用免注册 COM 激活加载的 .NET COM 对象。这很好用。我们使用的某些语言无法加载 COM，因此我们制作了一个 C++ Wrapper DLL，它使用 ACTCTX 从其嵌入的清单中激活 COM。也运作良好。

但是现在，我们有一个案例，我们的 C++ Wrapper 是由一个不属于我们的应用程序（我们称之为运行时）运行的代码加载的，该应用程序位于某个地方，而我们的应用程序位于其他地方。我们宁愿将 COM 对象部署在与应用程序部署相同的位置，而不是在运行时应用程序旁边。

这并不重要，因为概念保持不变，但运行器是 FourJ 的 Genero (fgl.exe)，调用我们的 C++ 包装器的代码位于 .42m 文件中。运行器 (fgl.exe) 与 Genero 一起安装，默认情况下位于 Program Files\FourJs 中，我们的应用程序位于另一个目录中，名称为我们公司的名称，即：Program Files\MyCompany

这与使用 Java 得到的类似。在一个地方运行时，在其他地方应用程序。

所以在我们的例子中，我们的 .42m 正确加载了 C++ Wrapper，包装器正确激活了 COM（与我们的 .42m 和 wrapper 位于同一目录中）但是一旦我们尝试实例化一个对象，我们就会得到一个“80070002”文件未发现错误。

我已阅读 Assembly Searching Sequence并注意到使用 Process Monitor 描述的行为。

所以会发生什么，因为最终运行的是 fgl.exe，Windows Side-By-Side 加载程序会查看：

1. C:\Program Files(x86)\FourJs\fgl\gen2.50\bin\MyCom.dll
2. C:\Program Files(x86)\FourJs\fgl\gen2.50\bin\MyCom.dll\MyCom.dll

虽然我的 COM 确实在 C:\Program Files(x86)\MyCompany\MyApplication\MyCom.dll

为了确认行为，我们将 COM 复制到与 fgl.exe 相同的目录中，并且正如预期的那样，它可以工作。

所以我希望能够在我的激活上下文中添加一个搜索目录，以便它在我的部署目录中查找这个 DLL。这可能吗 ？如果我找不到其他解决方案，我们最终会在该目录中部署我们的 COM，但这不正确。

谢谢

这是我的 COM 接口：

Init()如果 COM 接口已注册，或者使用并行程序集 (sxs) 与应用程序的清单一起注册，则以下函数有效。

但是，以下SetBitmap()功能仅在注册 COM 接口时才有效！

• 如果我使用配置了应用程序清单的 COM 接口，则函数调用失败并出现错误E_UNEXPECTED

• 如果我替换VTS_DISPATCH为VTS_BSTR，则函数调用成功并且有效。在这种情况下，调度程序似乎无法调度对象。

关于发生了什么的任何想法？

I'm researching about the configuration of a private registration free WinSxS with the plain provision of assembly manifest files, to stitch Delphi executables (COM clients) and .NET (C#) COM visible DLLs together at deployment and runtime.

I already studied the documentation available at MSDN "Interoperating with Unmanaged Code", the sections about "COM Callable Wrapper" and "How to: Configure .NET Framework-Based COM Components for Registration-Free Activation" in particular.

After even more than one week of research and being (re-)directed in cycles of insufficient documentation, I decided to place my 1st question ever here.

The planned deployment structure looks as follows:

Here's a short sketch about the implementation of the implementation of the Delphi native executables and the C# .NET COM server DLLs (I left out the examples for the native COM Servers, since this stuff already works well and is out of question).
I mainly followed what was provided at "Registration-Free Activation of COM Components: A Walkthrough". The main difference is that I'm utilizing Delphi rather than C, C++ or old VB as a native client.

TestDllConsoleApp.exe

TestDllConsoleApp.dpr

TestDllConsoleApp.manifest

(embedded with resource ID 1)

TestDllConsoleApp.exe.config

(deployed at the same file location as the executable)

CSharpCOMDll.dll

(will be deployed at the SharedLibs\MyCompany.Libs.Set1 directory)

Assemblyinfo.cs

COMImplClass1.cs

COMImplClass2.cs

CSharpCOMDll.manifest

(Embedded into the DLL with resource ID 2)

And finally the assembly manifest as resolved from the TestDllConsoleApp.manifest dependency entries:

MyCompany.Libs.Set1.manifest

It seems I'm halfway there, but still can't diagnose the actual problem.

There are two variants of failure right now (Please note, that deploying the managed COM server DLLs beside the executable instead of referring to the resolved manifests directory just works fine and as intended):

1. I completely remove the proxyStubClsid32 attribute in the global manifest:

   • Starting the executable ends up with an exception
     EOleSysError: Error in dll, clsid = {4CD39F25-0EB9-4CD0-9B4C-6F5DB5C14805}

   • Debugging the exception leads to a HRESULT value

2. I provide a proxyStubClsid32 attribute in the global manifest:

   • I'm not sure which GUID is actually needed for that attribute.
     As it's mentioned in the documentation it naturally seems to be a corresponding "co class ID" (CLSID) as mentioned in the comClass elements clsid attribute.
   • I alternatively tried to provide the LIBID GUID from the generated ,pas file there.

   Both variants leave me with a pretty useless error traceable with the sxstrace tool¹:

   Note that there wasn't any concise error/info message like

   before the Activation Context Generation screwed up. There's plenty of references indicating this particular error situation.
   Also the ubiquitous mentions of missing Visual C++ redistributable framework doesn't help here. I'm calling from Delphi, and that's something different.

3. Another attempt to reference the CSharpCOMDll.dll explicitly (another dependency in the executable manifest), and just place it into the SharedLibs got a successfully created Activation Context, but fails with a slightly different exception than before

Does anyone here know how to do what I want straightforward, or what can be done additionally (besides the sxstrace) to diagnose the problem in more depth.

I'm almost sure it must be possible to provide a deployment like this.

TL;DR;

• Is it even possible to provide a deployment structure like mentioned above, and maintain certain .NET COM server DLLs outside the referring executables locations?

Update:

Researching further today, I realized that (despite the very similar terminology), resolving the ActivationContext with a private SxS and resolving the location of .NET DLLs which serve for a COM callable wrapper instantiation are two completely distinct and separated mechanisms. I mostly got that from these 2 and some more of Jufeng Zhang's brilliant and in depth explaining blog articles:

• "COM activation, Registration Free COM activation, COM/.Net Interop, Registration Free COM/.Net Interop"
• "Registration Free COM/.Net interop"

The problem with the locating of the unregistered .NET assemblies (managed COM server DLLs) is, that this will only happen inside the applications deployment directory and below.

Using any method like specifying a <codebase> or <probing> element inside the configuration <runtime> section pointing outside the the directory where the .config file is deployed, simply doesn't work.

I verified that using the Sysinternals Process Monitor and the Fusion log viewer tool².

I'm not posting that as a final answer, because I'll try next somehow to trick that .NET mechanism to locate the managed COM server DLLs, using an assembly manifest, or native DLL specifying the dependencies and <probing> / <codebase> element to redirect the locating mechanism.

As a last resort (sic!) it seems to be even possible to provide your own customized appDomainManagerAssembly and appDomainManagerType in the application configuration under the <runtime> element.

Update II:

I'm afraid we have to go for managing the AppDomain ourselves using the CLR API from a native CLR Host.

Needs further investigation. One promising resource how to do that I found here:

"Customizing the Microsoft .NET Framework Common Language Runtime"

¹⁾ _{Excuse the German error messages please. I don't have an English version compiler at hand. But the translation given at google should work well.}

²⁾ _{So the question about better tools for diagnosing the problems, can be considered as solved.}

我有两个关于激活上下文 API 和 SxS 清单的问题。它们看起来很简单，但我仍然无法为它们找到任何好的答案。

我有两个文件名为 foo.dll 和 bar.dll 的 dll 库，它们都带有嵌入式清单，foo 取决于 bar。有没有办法为这两个分配文件名以外的 assemblyIdentity 名称？例如，如果我希望 bar.dll 的程序集标识为CompanyName.Subsection.bar？如果我像这样更改它的身份-尝试加载 foo.dll 时出现错误"Dependent Assembly CompanyName.Subsection.bar,type="win32",version="0.1.2.3" could not be found"。当然，如果我将名称程序集标识指定为文件名 ( <assemblyIdentity name="bar")，一切正常，但有没有办法使用这些带点的名称？

foo.dll

bar.dll