我无法在 Visual Studio 中同时构建项目的多个配置,但可以使用 MSBuild

发布于 2025-01-02 07:54:40 字数 2589 浏览 0 评论 0原文

我想在一个项目中同时构建两个配置。假设当我想构建发行版本,但我什至想构建调试版本(反之则不然)。

使用单个 Visual Studio 解决方案同时构建 x86 和 x64? 我尝试添加到 .csproj:

<Target Name="AfterBuild">
    <MSBuild Condition=" '$(Configuration)' == 'Release' " Projects="$(MSBuildProjectFile)" Properties="Configuration=Debug" RunEachTargetSeparately="true" />
</Target>

如果我尝试通过MSBuild构建项目,

MSBuild ConsoleApplication64.csproj /p:Configuration=Release /p:Platform=x86

它工作正常。两个配置构建正确,一切都很好。

问题是,如果我尝试使用 Visual Studio 构建它:发布版本正确构建,然后它开始构建调试版本,它给我:

正在将文件从“obj\x86\Debug\ConsoleApplication64.exe”复制到“bin\Debug\ConsoleApplication64.exe” c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2868,9): 错误 MSB3021: 无法将文件“obj\x86\Debug\ConsoleApplication64.exe”复制到“bin\Debug\” ConsoleApplication64.exe”。找不到文件“obj\x86\Debug\ConsoleApplication64.exe”。

前提条件:

  • Windows XP SP3 ITA
  • Visual Studio 2010 SP1 英语
  • 该项目是 C# 4.0 的空控制台应用程序(从技术上讲它不是,但我可以用它重现问题)。

(请注意,为了显示这些消息,我已激活了详细程度:正常菜单 工具选项项目和解决方案构建和运行MSBuild 项目构建输出详细程度

比较两个“一半”运行的输出后,差异在于“工作”一半的 csc 可执行文件被调用,而在另一个中它不是:

释放一半:

任务“Csc”(任务 ID:13) c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig /nowarn:1701,1702 /nostdlib+ /platform:x86 /errorreport:提示 /warn:4 /define:TRACE /reference:"C:\Programmi\Reference 程序集\Microsoft\Framework.NETFramework\v4.0\Profile\Client\Microsoft.CSharp.dll” /参考:“C:\ Programmi \参考 程序集\Microsoft\Framework.NETFramework\v4.0\Profile\Client\mscorlib.dll” /参考:“C:\ Programmi \参考 程序集\Microsoft\Framework.NETFramework\v4.0\Profile\Client\System.Core.dll” /参考:“C:\ Programmi \参考 程序集\Microsoft\Framework.NETFramework\v4.0\Profile\Client\System.dll” /调试:pdbonly /文件对齐:512 /优化+ /out:obj\x86\Release\ConsoleApplication64.exe /target:exe Program.cs Properties\AssemblyInfo.cs“C:\Documents 和 设置\m.alberti-cons\Impostazioni locali\Temp.NETFramework,版本=v4.0,配置文件=Client.AssemblyAttributes.cs” (TaskId:13) 完成执行任务“Csc”。 (任务ID:13)

调试一半:

任务“Csc”(任务 ID:41) 完成执行任务“Csc”。 (任务ID:41)

经过更多测试后,我注意到如果两半使用相同的 DefineConstants 那么就没有任何问题并且一切正常,但如果它们不同(如在release/中)调试)然后它不起作用。 :-(

I want to build two configurations at the same time of a project. Let's say that when I want to build the release version, but I want to build even the debug version (the opposite isn't true).

Starting with Use a single Visual Studio solution to build both x86 and x64 at the same time? I've tried adding to the .csproj:

<Target Name="AfterBuild">
    <MSBuild Condition=" '$(Configuration)' == 'Release' " Projects="$(MSBuildProjectFile)" Properties="Configuration=Debug" RunEachTargetSeparately="true" />
</Target>

And if I try to build the project through MSBuild,

MSBuild ConsoleApplication64.csproj /p:Configuration=Release /p:Platform=x86

it works correctly. The two configurations are built correctly and everything is good.

The problem is if I try to build it with Visual Studio: the release version is built correctly, and then it begins to build the debug version, and it gives me:

Copying file from "obj\x86\Debug\ConsoleApplication64.exe" to "bin\Debug\ConsoleApplication64.
c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2868,9): error MSB3021: Unable to copy file "obj\x86\Debug\ConsoleApplication64.exe" to "bin\Debug\ConsoleApplication64.exe". Could not find file 'obj\x86\Debug\ConsoleApplication64.exe'.

Pre-conditions:

  • Windows XP SP3 ITA
  • Visual Studio 2010 SP1 English
  • The project is an empty console application for C# 4.0 (technically it isn't, but I can reproduce the problem with that).

(Note that to have those messages I've activated the verbosity: normal from menu ToolsOptionsProjects and SolutionsBuild and RunMSBuild project build output verbosity.

After comparing the output of the two "half" runs, the difference is that in the "working" half the csc executable is called, and in the other one it isn't:

Release half:

Task "Csc" (TaskId:13)
c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig
/nowarn:1701,1702 /nostdlib+ /platform:x86 /errorreport:prompt /warn:4
/define:TRACE /reference:"C:\Programmi\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0\Profile\Client\Microsoft.CSharp.dll"
/reference:"C:\Programmi\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0\Profile\Client\mscorlib.dll"
/reference:"C:\Programmi\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0\Profile\Client\System.Core.dll"
/reference:"C:\Programmi\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0\Profile\Client\System.dll"
/debug:pdbonly /filealign:512 /optimize+
/out:obj\x86\Release\ConsoleApplication64.exe /target:exe Program.cs
Properties\AssemblyInfo.cs "C:\Documents and
Settings\m.alberti-cons\Impostazioni
locali\Temp.NETFramework,Version=v4.0,Profile=Client.AssemblyAttributes.cs"
(TaskId:13) Done executing task "Csc". (TaskId:13)

Debug half:

Task "Csc" (TaskId:41)
Done executing task "Csc". (TaskId:41)

After some more tests I've noticed that if the two halves use the same DefineConstants then there isn't any problem and everything works, but if they are different (as in release/debug) then it doesn't work. :-(

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

故乡的云 2025-01-09 07:54:40

由于 MSBuild 的增量生成机制,您无法在 Visual Studio 中进行生成跳过标记为已运行的目标。这里真正的问题是如何打破这种增量构建。 这个问题非常相关。

如果您使用 /verbosity=diag 进行构建,您会注意到 MSBuild 报告了一堆这样的内容:

已跳过目标“AssignTargetPaths”。之前已成功构建。

Microsoft 意识到此行为并考虑此 设计

我强烈建议不要这样做的一个可能的解决方法是使用 调用第二个构建执行任务。 Exec 任务只是一个命令行 shell,它将吃掉您提供给它的所有内容,但在您的情况下,它可能会破坏增量构建链。

<Exec Command="$(MSBuildToolsPath)\msbuild $(MSBuildProjectFile) /p:Configuration=Debug" Condition=" '$(Configuration)' == 'Release'" />

You can't build inside Visual Studio because of MSBuild's incremental build mechanism that skips targets marked as already run. The real question here is how to break this incremental build. This question is very related.

If you build with /verbosity=diag you will notice MSBuild reports a bunch of these:

Target "AssignTargetPaths" skipped. Previously built successfully.

Microsoft aware of this behavior and consider this by design.

A possible workaround, which I strongly advise against it, is invoking the second build using the Exec task. The Exec task is merely a command line shell which will eat everything you will feed it with, but in your case it can break the incremental build chain.

<Exec Command="$(MSBuildToolsPath)\msbuild $(MSBuildProjectFile) /p:Configuration=Debug" Condition=" '$(Configuration)' == 'Release'" />
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文