我的解决方案中有一个WiX捆绑软件安装程序。它由几个MSI项目和引导程序UI项目组成。一次全部构建时，一切正常。
由于需要对所有内容进行身份验证的新要求，我试图将程序集编译与安装程序编译分开，以便可以在两者之间登录。
我正在尝试使用两个单独的构建配置来执行此操作。一个仅构建应用程序程序集，另一个仅构建安装程序项目。当我从Visual Studio手动运行它们时，它们都正常工作。
问题是当我尝试从TFS构建定义中的单独任务中调用它们时。程序集，包括引导程序UI，均在第一个任务中成功编译。但是在第二个仅安装程序任务中，WiX项目将尝试重新编译引用的引导程序UI项目，并因缺少类型或名称空间错误而失败。
我尝试过从仅安装程序的构建配置中包括和删除boostrapper UI项目。无论哪种情况，我都会遇到相同的错误。是wixproj本身启动了底层的引导程序UI构建。
答案 0 :(得分：0)
好的，我认为这是您要尝试的操作，请在评论中纠正我，然后我可以相应地完善答案。
听起来您有一个解决方案，当在一个配置（例如CODE）中构建该解决方案时，它将仅编译.net项目，而在另一个配置（例如PACKAGE）中，仅构建WIX项目。我认为这种分离是问题的一部分。
从您的描述中，听起来还好像wix项目具有对其他代码项目的项目引用（最可能用于有效负载收集-但至少要建立构建依赖关系顺序）。
任何引用另一个项目的项目（wix或代码）将自动导致该项目的建立-在没有解决方案配置的情况下，它将默认为使用与主要项目相同的配置。这意味着，如果项目A具有称为CODE的配置，而项目B引用具有名为PACKAGE的配置，则构建项目B将导致A尝试使用配置PACKAGE进行构建-如果没有此配置，则它将成功（成功）将不会生成，因此项目A将无法找到它期望的依赖项。
在您的解决方案中，您应该具有两种配置，其中一种是另一种的超集。因此，仅用于构建代码的CODE配置是用于构建wix项目的PACKAGE配置的子集。当您在配置管理器中进行设置并构建解决方案时，您可以保证使用正确的配置来构建项目，而不是从主数据库推断配置。
然后，您可以在TFS构建中以两个步骤代替一个构建步骤。如果仍然需要拆分（因为您在两者之间进行了数字签名），则可以知道msbuild通过比较输入和输出的时间戳来进行增量生成。这意味着，如果您构建项目A，然后对其进行数字签名，则构建项目B（引用A）将尝试构建项目A，但它将确定A的输出比输入新，而不替换装配件。最终，这意味着您可以安全地在配置CODE下构建解决方案，对程序集进行签名，然后在配置PACKAGE（这是CODE的超集）下再次构建解决方案，而无需替换已签名的程序集。
在相关说明中，wix目标文件具有挂钩点，用于对捆绑包进行签名，这是wix项目构建的一部分。这可能比事实之后尝试使用PowerShell对其进行签名要好。