处理安装程序中的常见文件的常见/最佳方法是什么？
我目前正在开发一个项目，该项目将被其他几个项目使用。该项目包含：
- 一些本机 dll
- 一些托管 dll，它们 p/调用本机
- 数据 - 可能相当大
我想为此项目提供单独的安装程序，其他项目将检测它是否已安装并在可用时使用它。
处理这个问题的最佳方法是什么？
我考虑过：
- 仅使用数据创建安装程序，让所有其他项目在自己的 dll 上分发我的 dll，
- 创建包含所有内容的安装程序，并让其他项目找到我的 dll 并加载它们。
我在#2 方面遇到技术困难，其他项目将如何使用我的 dll？我宁愿避免反思。如果我 gac dll，我的托管 dll 将如何找到本机 dll？
编辑： 我不是在寻找具有特定功能的特定打包程序/安装程序。我只是问概念上的最佳实践是什么。
I currently on a project which will be used by a handful of other project. The project contains:
- some native dlls
- some managed dlls that p/invoke into native ones
- data - possibly quite big
I would like to provide separate installer for this project and other projects would detect if it is installed and use it if available.
What would be the best way to handle this ?
I have considered:
- create installer with data only and have all other projects distribute my dlls on their own
- create installer with everything and have other project locate my dlls and load them.
I have technical difficulty with #2, how would other projects use my dll? I rather avoid reflection. If I gac the dlls, how would my managed dlls find the native dlls?
EDIT:
I'm not looking for specific packager/installer with specific feature. I'm simply asking what is the best practice conceptually.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我以前从未真正使用过合并模块，所以我想我应该玩一下，看看它们是如何工作的。
合并模块允许您将常见的安装程序功能打包到可重用的模块中（通常是安装组件，但也可能是一些安装 UI）。使用此合并模块的每个应用程序安装程序都可以自由地将这些组件安装在他们想要的任何地方（例如与应用程序一起），并且如果他们确实安装了这些组件的多个副本，则将安装这些组件，但是如果他们遵守纪律并且全部指定相同的安装位置，那么将仅安装组件的一份副本。
如果这些组件安装到一个公共位置，那么事情就会非常顺利，因为只有在所有依赖的安装程序都被卸载后，这些组件才会被卸载。这比为公共组件使用单独的安装程序要简单得多，因为这意味着每个应用程序安装程序不需要担心在卸载时是否应该卸载此公共安装程序（这可能会破坏使用这些组件的所有其他应用程序）成分）。
然而，整个安排的棘手之处在于版本控制 - 如果应用程序A安装CommonLib v1.0，然后应用程序B > 安装CommonLib v1.1，会发生什么？
如果使用多个目录来分隔版本，那么您应该确保由合并模块决定这些目录的名称，例如您的公共库的目录结构可能如下所示
： 1. 如果不小心保持公共安装目录不变，则不会覆盖v1.0文件。
（请注意，可能还有其他更复杂的方法可以让合并模块指定安装位置，但我知道上面的方法是有效的，所以我没有过多研究它，因为它可能取决于您用来创建 MSI 的内容 - Wix / InstallShield 等...）
此外，如果您将版本分离到不同的目录中，您还需要某种机制来允许您的库或最终用户应用程序识别相关文件的安装位置（例如注册表项） ) - 这就是安装到 GAC（或者可能只是将托管库与应用程序一起安装）的优势所在，因为这意味着该逻辑可以嵌入到库本身中。
最终你如何做到这一点将取决于你的具体要求，但我希望这至少给了你一些想法。
I've never actually used merge modules before so I thought I'd have a play and see how they worked.
A merge module allows you to package up common installer functionality into a re-usable module (typically installation components, but possibly also some setup UI). Each application installer that uses this merge module is free to install these components wherever they want (for example alongside their application) and if they do multiple copies of these components will be installed, however if they are disciplined and all specify the same install location then only one copy of the components will be installed.
If the components are installed to a common location then things work quite nicely in that the components are only uninstalled once all the dependent installers have been uninstalled. This is far simpler than having a separate installer for the common components as it means that each application installer doesn't need to worry about whether or not it should uninstall this common installer when being uninstalled (which could potentially break all other applications which use these components).
The tricky thing about this whole arrangement however is versioning - if App A installs CommonLib v1.0 and then App B installs CommonLib v1.1, what should happen?
If multiple directories are used to separate versions then you should make sure that it is the merge module that decides the names of these directories, for example the directory structure of your common library might look like this:
This way even if an application installs v1.1 while accidentally leaving the common installation directory unchanged, it won't overwrite the v1.0 files.
(Note that there might be other more sophisticated ways of having the merge module specify the installation location, but I know that the above works so I didn't look into it too much as it probably depends on what you use to create your MSI - Wix / InstallShield etc...)
Also if you separate out your versions into different directories you will also need some mechanism to allow either your library or the end user Application identify where the the relevant files have been installed to (for example a registry key) - this is where installing to the GAC (or maybe just installing the managed library alongside the application) has its advantages as it means that this logic can be embedded into the library itself.
Ultimately how you do this will depend on your specific requirements, but I hope that this has at least given you some ideas.
正如 Kragen 提到的，看看 MSI 封装流程。我们使用 AdminStudio，它非常适合打包您的二进制文件。或者你也可以使用 WIX（这是命令行打包，通常与构建集成）
as Kragen mentioned, have a look at MSI Packaging process. We Use AdminStudio which is quite good to packaging up your binaries. Or you could WIX as well (which is command line packaging which usually gets integrated with the build)