【问题标题】:Using NuGet with WIX doesn't work when building release构建版本时使用 NuGet 和 WIX 不起作用
【发布时间】:2015-04-17 20:34:14
【问题描述】:

我有一个包含 WIX 项目的解决方案。我几个月前通过 NuGet 添加了 WIX,它的版本是 3.8.1128.0 在我的开发过程中构建时一切正常。

当我准备好发布时,我在 SVN 中分支文件夹,然后将分支拉到我的开发机器上。当我在分支中打开解决方案时,它无法打开 WIX 项目。 (它在项目旁边显示“(加载失败)”。

当我尝试从 VS 重新加载项目时,出现错误

导入的项目“c:\Projects\xxxxx\yyyyy\SolutionName\packages\WiX.Toolset.3.8.1128.0\tools\wix\wwix.targets” 没找到。确认声明中的路径是 正确,并且该文件存在于磁盘上。

我尝试添加Wix Toolset (unofficial) NuGet 包,但是当我转到解决方案管理 NuGet 包的“在线”选项卡时,我只看到 3.9.1208.0 版本。

目标是将包含二进制文件和 wix msi 包项目的解决方案放到构建服务器上,但如果我不能依赖 NuGet 安装 WiX,我不知道如何进行设置在另一台机器上。

【问题讨论】:

    标签: visual-studio-2013 wix nuget nuget-package nuget-package-restore


    【解决方案1】:

    查看 WiX 工具集 NuGet 包,它会修改 WiX MSBuild 文件的路径,以便从 NuGet 包中使用 MSBuild 文件,而不是在机器上安装 WiX 时使用它们所在的C:\Program Files\WiX。项目文件的相关部分如下所示:

      <PropertyGroup>
        <WixTargetsPath Condition=" '$(WixTargetsPath)' == '' AND '$(MSBuildExtensionsPath32)' != '' ">$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>
        <WixTargetsPath Condition=" '$(WixTargetsPath)' == '' ">$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>    
      </PropertyGroup>
    
      <PropertyGroup>
        <WixToolPath>$(SolutionDir)packages\WiX.Toolset.3.8.1128.0\tools\wix\    </WixToolPath>
        <WixTargetsPath>$(WixToolPath)wix.targets</WixTargetsPath>
        <WixTasksPath>$(WixToolPath)WixTasks.dll</WixTasksPath>
      </PropertyGroup>
      <Import Project="$(WixTargetsPath)" />
    

    由于这是一个 WiX 项目文件,因此 Import 元素没有检查 WiXTargetsPath 是否存在的条件,因此如果 Wix.targets 文件丢失,Visual Studio 将无法加载项目。不幸的是,添加一个条件,如下所示,同时允许 Visual Studio 加载项目并不能修复构建。

      <Import Project="$(WixTargetsPath)" Condition="Exists($(WixTargetsPath))"/>
    

    如果项目文件中存在上述条件,那么在构建项目时 Visual Studio 将自动恢复 WiX NuGet 包,如果您安装了最新版本的 NuGet,但您仍然会收到有关缺少构建目标的构建错误维克斯项目。此构建错误只能通过在恢复 WiX NuGet 包后再次关闭并重新打开解决方案来修复。

    在构建服务器上,我将创建一个预构建步骤,在构建 WiX 项目之前使用 NuGet.exe restore 来恢复 NuGet 包:

    NuGet.exe restore path\to\the\solution\yoursolution.sln
    

    这将恢复 WiX 包。然后,您可以构建 WiX 项目,而不会出现任何关于缺少 WiX 目标文件的错误。

    另一种方法是将包目录签入源代码管理。但是,这会将二进制文件添加到您可能不想做的源代码管理中。

    WiX.Toolset.3.8.1128.0 也可从 nuget.org 获得,但 NuGet 对话框将显示最新版本。您可以使用包管理器控制台安装特定版本的 NuGet 包。当 NuGet 3.0 发布时,您应该能够从 NuGet 对话框执行相同的操作。

    【讨论】:

    • 如果你在 Visual Studio 中构建 NuGet 包,NuGet 将自动恢复它们。它不会在构建服务器上这样做。对于构建服务器,您将需要运行预构建步骤或使用已弃用的启用包还原,以便恢复包。这适用于大多数 NuGe t 包。 WiX 似乎是一种特殊情况,因为构建目标文件用于定义项目构建信息,而不仅仅是扩展现有目标文件。
    • WiX NuGet 包使项目自包含,因此您不必在机器(开发人员或构建服务器)上单独安装 WiX。
    • 一般来说,使用 NuGet,您只需在另一台机器上打开解决方案,一切都会正常运行。问题在于 WiX NuGet 包和 WiX 项目。 WiX NuGet 包正在尝试覆盖单独安装的 WiX.targets 文件。由于这定义了项目,因此会导致 Visual Studio 出现问题。其他 NuGet 包将自定义 MSBuild 目标文件添加到项目中,NuGet 还原将处理它们而不会出现任何错误。该问题特定于 WiX NuGet 包。
    • 具体来说,这应该发生在任何为项目定义 msbuild 目标的 NuGet 包中。问题在于,为了知道要恢复哪些包,Visual Studio 必须加载所有项目文件。如果项目文件依赖于必须通过 NuGet 安装的 .target 文件,则项目将无法加载,但仍会下载 NuGet 包。现在 .targets 文件已经存在,下次启动 Visual Studio 时,它应该可以正常工作了。这就是为什么 Matt Ward 建议在启动 Visual Studio 之前使用“引导”脚本来加载 NuGet 包。
    • 太棒了,5 年后这个解决方案仍然有效!
    猜你喜欢
    • 2014-01-15
    • 2019-08-16
    • 2023-03-13
    • 2016-03-05
    • 2020-10-05
    • 2023-03-16
    • 1970-01-01
    • 2023-01-13
    • 1970-01-01
    相关资源
    最近更新 更多