我觉得这个问题很有趣,主要是因为 MSI 不太适合这个问题。因此,在设计您的方法时,这里有一些注意事项:
维修中会发生什么?
问题中的文件是否已版本化,如果是,用户是否可以提供比您包含的版本更低的版本?(或者类似地,其余的文件版本控制规则是否会导致类似的情况?)如果是这样,您将希望避免让您的 .msi “拥有”该文件,因为它会用它知道的文件覆盖用户选择的文件. 此外,除非有理由相信用户提供的路径将保持可用,否则您必须在修复发生之前处理它丢失的情况。
卸载时会发生什么?文件应该被删除还是留下?你会知道它的名字吗?(如果名称可以变化但您需要删除文件,请考虑“记住属性”模式。)
你有什么选择?
“半自定义操作”可能能够以几种不同的方式解决这个用例。您可以为DuplicateFile
table或MoveFile
table创建临时条目。或者,如果您愿意做足够的扭曲来填写Directory
表格和Media
表格,您甚至可以填充File
表格。我希望这些都很难正确管理。(同样,不要忘记修复和删除 - 后者可能需要临时RemoveFile
表条目。)或者您可以执行完整的自定义操作,直接复制或移动文件。或者您可以重新构建应用程序:
作为用户文件有意义吗?或许该文件是一种配置形式,需要跨整机共享,甚至由网络管理员配置。如果是这样,您可能最好使用上述方法之一,因此它由管理员安装,然后受到标准 Windows 文件系统安全性的保护。但如果它真的是一个用户配置文件,也许它应该在你的应用程序中管理或直接由用户管理。