我怎样才能在 vs 2010 安装项目中为两个不同的发行版本拥有不同的属性等？
我想要的是我的解决方案中只有一个安装项目，并且我希望能够在一台计算机上同时安装“release1”和“release2”版本（如版本 debug/release1/release2）。因此，release1 版本需要自己的程序文件夹、产品代码和快捷方式等，而release2 版本也需要这些东西自己独特的版本。
然而，安装项目似乎没有为两个不同的发行版本存储单独的属性。似乎唯一不同的是输出路径，当然他们使用不同的生成的exe。
我是否必须迁移到 Wix 才能解决这个问题？或者我在这里缺少一些简单的东西？您无法配置安装程序为两个不同的发行版本执行不同的操作，这似乎有点愚蠢。到目前为止，看起来我必须制作另一个安装项目，这会很烦人，因为我不喜欢维护一个安装项目，更不用说 2。
提前感谢您的帮助。
艾萨克
What I want is to only have one setup project in my solution, and I want to be able to install 'release1' and the 'release2' versions (as in versions debug/release1/release2) simultaneously on one machine. So, the release1 version needs its own program folder, product code and shortcuts and such, and the release2 version needs its own unique versions of these things too.
It seems however the setup project doesn't store seperate properties for the two different release versions. Seems all thats different is the output path, and of course they use the different generated exes.
Am I going to have to move to Wix to solve this problem? Or is there something simple I'm missing here? It seems kind of stupid that you can't configure the installer to do different things for two different release versions. So far its looking like I'll have to make another setup project, which is going to be annoying because I don't like having to maintain one setup project let alone 2.
Thanks in advance for the help.
Isaac
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
创建两个不同的安装项目，一个称为生产设置，一个称为测试设置可能是最简洁的方法，因为它使操作系统相信您正在交付两种不同的产品，即事实上这里的情况就是这样。
正如您自己所建议的，迁移到 WiX 确实有一个优点，即您可以在两个安装项目中重复使用部件，例如避免两次维护相同的文件列表的需要。
当然，还有另一种选择。如果您的生产设置和测试设置项目几乎相同，并且您只需交换一些 GUID（例如产品或包代码，以使 MSI 考虑它们）不同），创建一个简单的脚本，将第一个安装项目文件复制到第二个位置并交换文件内的 GUID（该文件只不过是一个 XML 文件）。因此，您只需维护第一个项目文件，并可以通过重新运行脚本轻松重新生成第二个项目文件。
就我个人而言，我在 VBS 中做这样的事情，但您也可以使用 powershell 来完成此操作，或者用任何能够进行 XML 或 RegEx 处理的语言编写一个简单的工具。
Creating two different setup projects, one called Production Setup and one called Test Setup might be the cleanest way, since it makes the OS believe you are delivering two different products, which is in fact the case here.
Moving to WiX, as you suggested by yourself, has indeed the advantage that you can reuse parts in both your setup projects, avoiding the need to maintain the same list of files twice, for example.
There is, of course, another option. If your Production Setup and your Test Setup projects are almost identical, and you need just to exchange some GUIDs (the product or package code, for example, to make MSI consider them to be different), create a simple script which copies the first setup project file to a second location and exchanges the GUIDs within the file (which is nothing but an XML file). So you have only to maintain the first project file and can regenerate the second one easily by rerunning the script.
Personally I am doing such stuff in VBS, but you can also use powershell for that or write a simple tool in any language capable of doing XML or RegEx processing.