c++ - 自定义 "base"项目的事件检测 list 以满足 "derived"项目的需要

Question

我正在处理两个共享大部分代码的不同 C++ DLL 项目。 因此，我有一个编译为 Base.lib 的基础项目和两个编译为 Derived1.dll 和 Derived2.dll 的“派生”项目并链接到 Base.lib。这些派生的 DLL 应独立运送。用户甚至不知道他们是相关的。

现在我希望我的两个 DLL 都是 windows event providers 。我想要记录的所有事件都发生在 Base.lib 中。因此，我向该项目添加了一个 Instrumentation.man 并使其成为构建的一部分。 其内容大致如下所示:

<?xml version="1.0" encoding="UTF-16"?>
<instrumentationManifest xsi:schemaLocation="http://schemas.microsoft.com/win/2004/08/events eventman.xsd" xmlns="http://schemas.microsoft.com/win/2004/08/events" xmlns:win="http://manifests.microsoft.com/win/2004/08/windows/events" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:trace="http://schemas.microsoft.com/win/2004/08/events/trace">
  <instrumentation>
    <events>
      <provider name="Company-Provider-Base" guid="{12345678-1234-1234-1234-1234567890ABCD}" symbol="provider" resourceFileName="some/path/to.dll" messageFileName="some/path/to.dll" message="$(string.provider.message)">
        <events>
            ...
        </events>
      </provider>
    </events>
  </instrumentation>
  <localization>
    <resources culture="en-US">
      <stringTable>  
        <string id="provider.message" value="Base Provider" />
        ...
      </stringTable>
    </resources>
  </localization>
</instrumentationManifest>

我使用mc.exe 将其编译成一个资源文件和一个头文件。头文件包含在我的 Base 项目的其他源文件中。

现在效果出奇的好!两个 DLL 的所有事件都已正确记录。

但是，当然，这两个 DLL 现在共享具有相同名称、GUID 和消息的相同提供程序。

所以，我的实际问题是: 我怎样才能使 Instrumentation.man 中的 provider 元素以我的 DLL 项目可以填写自己的 name 的方式进行自定义，guid 和 message 属性？

我正在使用 WiX 创建我的安装套件。 WiX 允许我自定义 provider 元素的 resourceFileName 和 messageFileName 属性(两者都指向原始文件中的虚拟对象)部署在目标系统上，以便可以正确引用它们。然而，WIX 没有提供类似的方式(至少我没有看到)来平滑地改变其他属性，这正是我想要的。

我还注意到 WiX 提供自定义 parameterFileName 属性。不幸的是，我找不到这些参数如何工作的任何信息。我知道我可以将 %%n 放入 list 中的字符串中，然后将插入标识符为 n 的参数。但是我不明白在哪里以及如何声明这些参数，另外，我不知道我是否可以在我想要自定义的属性中使用它们，这样它们对我一点帮助都没有。

Answer 1

我最终编写了自己的 XML 修改工具(在 C# 中，如 here 所述，但任何其他语言也可以)，它获取 list 文件和解决方案名称并相应地替换属性值。

为了使这项工作自动进行，我向 Base 项目添加了一个 Pre-Build Event，它调用此工具并将 list 文件和 $(SolutionName) 传递给它。

此解决方案既不美观也不易扩展，但它确实有效。