我有应用程序A和B,它们都使用共享组件S.如果S是一个DLL程序集,我只需将它的一个副本作为私有部件。但S是一个EXE,A和B通过一个协议与它交谈。当A和B都在运行,他们必须说话的S.可能出现的情况相同的实例:部署EXE在多个应用程序之间共享的最佳方式
- 用户安装A和S与它一起安装,因为A依赖于S.后来的用户安装B,但S没有安装,因为它已经在那里。
- 用户安装A和S与它一起安装。后来用户安装了B,它随S的更新版本一起被替换为新版本。
- 安装了A和B(和S)。用户卸载B,但由于A仍然存在,所以S被保留。后来用户卸载A和S也被卸载,因为没有应用程序依赖它了。
S的新版本将与旧版本的A和B兼容。如果协议改变,S将支持旧协议和新协议等。
这种情况下最好的部署策略是什么?我正在使用Windows Installer(MSI)。将S作为独立应用程序与单独的MSI并从其他MSI调用MSI似乎是件好事,但也许有更好的方法。也许MSM?..我想保持安装简单。预先感谢您的答案。
尼克,感谢您指向我的WiX。你提出的解决方案看起来很有希望,但是在MSM中使用S并通过共同碎片合并它会更好吗?这将确保A和B的GUID和S的路径相同。您的意见是什么? – Yuriy 2012-03-01 12:45:00
此外我搜索了msidbComponentAttributesSharedDllRefCount,发现这个http://blogs.msdn.com/b/astebner/archive/2005/08/30/458295.aspx。在“2005年9月1日2:30 AM”的评论中,Aaron Stebner说:“Windows安装程序还为系统上安装的所有组件的组件ID保留一个内部参考计数,无论它是否安装这些文件中包含的文件组件,并且不管MSI组件表中的组件属性设置是什么。“,所以也许我不需要设置msidbComponentAttributesSharedDllRefCount? – Yuriy 2012-03-01 12:45:13
为了回答您的问题,我认为a)是的,MSM在这种情况下适用于可移植性和重用,b)文章的确似乎表明您不需要设置属性。 – 2012-03-01 16:42:36