我目前正在开展一个项目，该项目将由少数其他项目使用。该项目包含：
我想为这个项目提供单独的安装程序，其他项目会检测它是否已安装并在可用时使用它。
处理此问题的最佳方法是什么？
我考虑过：
我对＃2有技术上的困难，其他项目如何使用我的dll？我宁愿避免反思。如果我搞砸dll，我的托管dll怎么会找到原生的dll？
编辑： 我不是在寻找具有特定功能的特定打包器/安装程序。我只是问概念上最好的做法是什么。
答案 0 :(得分：1)
之前我从来没有真正使用过合并模块，所以我觉得我有一个游戏，看看它们是如何工作的。
合并模块允许您将常用安装程序功能打包到可重复使用的模块中（通常是安装组件，但也可能是某些设置UI）。使用此合并模块的每个应用程序安装程序都可以随意在任何他们想要的地方安装这些组件（例如，与他们的应用程序一起），如果他们执行这些组件的多个副本，则会安装这些组件，但是如果它们是规范的并且都指定了相同的安装位置，那么只安装一个组件副本。
如果组件安装在一个公共位置，那么事情就可以很好地完成，因为只有在卸载了所有相关安装程序后才卸载组件。这比为公共组件安装单独的安装程序要简单得多，因为这意味着每个应用程序安装程序在卸载时都不需要担心它是否应该卸载这个通用安装程序（这可能会破坏使用这些安装程序的所有其他应用程序）组件）。
关于这整个安排的棘手问题是版本化 - 如果 App A 安装 CommonLib v1.0然后 App B 安装 CommonLib v1.1，会发生什么？
如果使用多个目录来分隔版本，那么您应该确保它是决定这些目录名称的合并模块，例如公共库的目录结构可能如下所示：
Program Files
Common Lib // This is the folder that installers must specify
*Common data files*
v1.0
*v1.0 Files*
v1.1
*v1.1 Files*
这种方式即使应用程序安装v1.1而意外地保持公共安装目录不变，也不会覆盖v1.0文件。
（请注意，可能有其他更复杂的方法让合并模块指定安装位置，但我知道上面的工作原理因此我没有太多考虑它，因为它可能取决于你用来创建什么你的MSI - Wix / InstallShield等......）
此外，如果您将版本分离到不同的目录中，您还需要一些机制来允许您的库或最终用户应用程序识别相关文件的安装位置（例如注册表项） - 这是安装到GAC（或者可能只是在应用程序旁边安装托管库）有其优点，因为这意味着可以将此逻辑嵌入到库本身中。
最终你如何做到这一点取决于你的具体要求，但我希望这至少能给你一些想法。
答案 1 :(得分：-1)