未为此项目设置 OutputPath 属性答案

【问题标题】：The OutputPath property is not set for this project未为此项目设置 OutputPath 属性
【发布时间】：2012-02-23 14:24:22
【问题描述】：

当我尝试在 Visual Studio 2008 中从 x86 调试模式编译我的项目时。我收到此错误。当我查看投诉项目的属性组时，我看到设置了输出路径。

这是该 .csproj 文件的属性组部分

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
  <DebugSymbols>true</DebugSymbols>
  <OutputPath>bin\x86\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE</DefineConstants>
  <BaseAddress>285212672</BaseAddress>
  <FileAlignment>4096</FileAlignment>
  <DebugType>full</DebugType>
  <PlatformTarget>x86</PlatformTarget>
 <ErrorReport>prompt</ErrorReport>

有人能解释一下吗？

注意：当我编译这个 Debug 和 Any CPU 时，它可以工作。

更新： 错误 1 未为此项目设置 OutputPath 属性。请检查以确保您指定了有效的配置/平台组合。配置='调试'平台='x86'

【问题讨论】：

好的，您使用什么配置和平台？ Debug + x86 还是别的什么？
是的VS配置管理器我选择debug + x86
@DmitryShkuropatsky 更新错误信息
看起来正确。解决方案中是否有其他项目可能导致错误？
@DmitryShkuropatsky 你是对的，这是另一个有问题的项目。但是VS抱怨正在编译的项目

标签： c# visual-studio

【解决方案1】：

在 Visual Studio 中通过 ConfigurationManager 添加新配置后，我遇到了完全相同的错误。

当为整个解决方案（和每个项目）添加“生产”配置时，OutputPath 元素没有添加到 .csproj 文件中。

为了解决这个问题，我转到项目属性中的 Build 选项卡，将 OutputPath 从 \bin\Production\ 更改为 \bin\Production（删除了结尾的 \）并保存了更改。这会在 .csproj 文件中强制创建 OutputPath 元素，并且项目已成功构建。

对我来说听起来像是一个小故障。

【讨论】：

很好地抓住了这个反复无常的错误。永远不会想到一个斜线可以产生如此大的不同。有一个很好的答案徽章。
在我的情况下，构建一个 proj 文件，any cpu 和 anycpu 之间的区别是问题所在，但您的帖子帮助我看到了这一点。
谢谢罗曼，你拯救了我的一天……要是我能对你的答案投票 100 次就好了！ :)
刚在VS 2017 v15.6.6遇到这个，培根保存了，谢谢！
@Joshua Drake，这是使用 VSTS 时的一个重要问题。 Visual Studio Online 使用“any cpu”，而本地 Visual Studio 使用“anycpy”。对构建脚本很重要。

【解决方案2】：

如果您的解决方案中有一个项目引用了无法找到的程序集，则您可以在 VS 2008 中看到此错误。如果程序集来自不属于您的解决方案但应该属于的另一个项目，则可能会发生这种情况。在这种情况下，只需将正确的项目添加到解决方案中即可解决。

检查解决方案中每个项目的参考部分。如果其中任何一个在其旁边有一个带有红色 x 的引用，那么您已经找到了您的问题。解决方案找不到该程序集引用。

错误信息有点混乱，但我已经看过很多次了。

【讨论】：

就我而言，这是一个“黄色警告”

【解决方案3】：

如果您使用的是 WiX，请查看此（有一个错误） http://www.cnblogs.com/xixifusigao/archive/2012/03/20/2407651.html

有时新的构建配置会被添加到文件更下方的.wixproj 文件中，也就是说，通过其他不相关的 XML 元素与它们的同级配置定义分开。

只需编辑.wixproj 文件，使定义构建配置的所有<PropertyGroup> 部分彼此相邻。（要在VS2013中编辑.wixproj在解决方案资源管理器中右键单击项目，卸载项目，再次右键单击->编辑YourProject.wixproj。编辑文件后重新加载。）

【讨论】：

谢谢，这为我解决了问题。我添加到项目中的配置越多，我就有很多奇怪的行为。一旦我清理了项目文件，一切正常。（这个错误是在 2012 年首次报告的？太棒了...）
谢谢，这也为我解决了问题

【解决方案4】：

这发生在我身上，因为我将以下行移到了 .csproj 文件的开头附近：

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets"/>

它需要放在定义您的配置|平台的 PropertyGroups 之后。

【讨论】：

我刚刚使用 .NET Reflector 导出了一堆 DLL/EXE，它生成了错误的 .CSPROJ，就像你描述的那样。哇，以前从未见过这个。

【解决方案5】：

在设置为构建 .csproj 而不是构建管道中的 .sln 后，Azure DevOps 的输出出现了这个问题。

我的解决方案：编辑受影响项目的 .csproj，然后复制整个文件

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCpu' ">

节点，粘贴，然后修改第一行如下：

    <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|any cpu' ">

原因是，在我的情况下，错误说

Please check to make sure that you have specified a valid combination of Configuration and Platform for this project.  Configuration='release'  Platform='any cpu'.

为什么 Azure 想要使用“any cpu”而不是默认的“AnyCpu”对我来说是个谜，但这个 hack 有效。

【讨论】：

按照您的想法，我发现在我的情况下，我不需要在项目中进行更改，而是在 DevOps 的 Visual Studio 构建步骤中，我设置了配置字段以使用变量AnyCpu 值。
@donatasj87 你介意发布这个字段的完整值吗？
完整值完全相同，这在 TFS 构建中也应该有效。它只需要匹配在 .csproj 文件中设置的值。你可以在这张图片中看到：pasteboard.co/JbdvBT5.png
您可能还需要为Release|x86添加属性组

【解决方案6】：

Visual Studio 中显示的项目（假设是 A）的错误没有问题。当我逐行查看每个项目的构建输出窗口时，我看到它正在抱怨另一个项目 (B)，该项目 (B) 在项目 A 中被称为程序集。项目 B 添加到解决方案中。但它没有在项目 A 中被称为项目参考，而是作为来自不同位置的装配参考。该位置包含为平台 AnyCpu 编译的程序集。然后我从项目 A 中删除了程序集引用，并添加了项目 B 作为参考。它开始编译。不确定此修复程序是如何工作的。

【讨论】：

Deffo 尝试使用 \p:Platform="AnyCPU" 而不是 \p:Platform="Any CPU"。这对我有用！看这个很久了！
AnyCPU（没有空间）也对我有用。谢谢李。
在将“解决方案或 packages.config 的路径”从 .sln 更改为 .vbproj 之后，我在 TFS 2017 上运行构建过程时遇到了错误。将 BuildPlatform 更改为 AnyCPU 也对我有用。请参阅此处“平台”下的注释：docs.microsoft.com/en-us/vsts/build-release/tasks/build/…
在我的例子中，当从 TFS 启动构建时，"any cpu" 是 BuildPlatform 的默认值。改成"AnyCPU" 解决了这个问题。
这是 2020 年 - AnyCPU vs Any CPU 仍然是个麻烦制造者。我正在使用 VS2019 并且仍然在新项目中使用它。 MS 你为什么要惩罚开发者社区？

【解决方案7】：

我遇到了同样的错误，但问题原来是因为我在我的解决方案中创建了一个新配置，而该配置在另一个解决方案的引用程序集中不存在。

这可以通过打开相关解决方案并向其添加新配置来解决。

在我已经确认我的解决方案中的所有项目都具有正确的配置之后，这篇文章给了我检查引用程序集的想法：

http://gabrielmagana.com/2010/04/solution-to-the-outputpath-property-is-not-set-for-this-project/

【讨论】：

【解决方案8】：

如果您仅在尝试使用 MSBuild 从命令行编译项目时收到此错误（就像我的情况一样），那么解决方案是使用类似 /p:OutputPath=MyFolder 的参数手动将输出路径传递给 MSBuild。

【讨论】：

【解决方案9】：

我遇到了同样的错误，所以我查看了项目设置，在“构建”部分有“构建输出路径”选项。值是空的。于是我填写了“bin\”值一个错误就消失了。它解决了我的问题。

【讨论】：

【解决方案10】：

添加新配置并删除“调试”和“发布”配置后，我遇到了同样的问题。在我的情况下，我使用 cmd 文件来运行构建和发布过程，但抛出了同样的错误。 我的解决方案： 在 csproj 文件中：

<Configuration Condition=" '$(Configuration)' == '' ">Debug< /Configuration>

如果我没有明确指定配置，则将配置设置为“调试”。将节点值从“调试”更改为我的自定义配置后，一切顺利。希望这对阅读本文的人也有帮助:)

【讨论】：

本论坛帖子中提到了此解决方案的详细信息。 social.msdn.microsoft.com/Forums/vstudio/en-US/…

【解决方案11】：

我有：

右键单击项目有问题 -> 卸载项目
右键单击项目并选择编辑 *.csproj

复制粘贴现有配置中的配置，适用于特定名称和目标平台（我有 Release | x64）：

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
  <OutputPath>bin\x64\Release\</OutputPath>
  <DefineConstants>TRACE</DefineConstants>
  <Optimize>true</Optimize>
  <DebugType>pdbonly</DebugType>
  <PlatformTarget>x64</PlatformTarget>
  <ErrorReport>prompt</ErrorReport>
  <CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
  <Prefer32Bit>true</Prefer32Bit>
</PropertyGroup>

右键项目 -> 重新加载项目
重建项目/解决方案

【讨论】：

【解决方案12】：

另一种疯狂的可能性：如果您遵循将 Branch\Main、Main 和 Release 彼此相邻放置的简单源代码控制安排，并且最终以某种方式从 Main 而不是 Branch\Main 添加现有项目（假设您的工作解决方案是 Branch\Main），您可能会看到此错误。

解决方案很简单：引用正确的项目！

【讨论】：

【解决方案13】：

我在将项目添加到解决方案然后从同一解决方案中的另一个项目引用它时遇到了这个问题 - 引用上方出现黄色警告图标，请注意路径为空。

解决方案与@Amzath 建议的类似，我的项目正在使用不同的目标框架编译，例如。 .NET 4.0 与 4.5。

【讨论】：

【解决方案14】：

在我的情况下，我的应用程序的构建地址设置为另一台已关闭的计算机，因此我将其打开并重新启动 VS，问题就解决了。

【讨论】：

【解决方案15】：

另一个原因：您在解决方案 X 中将项目 A 的项目引用添加到项目 B。但是，已经包含项目 A 的解决方案 Y 现在已损坏，直到您也将项目 B 添加到解决方案 Y。

【讨论】：

【解决方案16】：

我遇到了同样的问题，只需编辑 .wixproj 即可拥有所有 <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... > 元素并排。

这解决了我的问题

【讨论】：

【解决方案17】：

我使用的 WiX 项目在配置管理器中为x64 全面设置。在为解决方案创建自定义操作项目时，它默认将 x86 文件中的所有内容设置为 .csproj。所以我卸载了项目，通过将所有 x86 更改为 x64 对其进行了编辑，保存，重新加载，然后就可以继续使用了。

我不明白为什么我必须这样做。配置管理器设置为 x64，但不会在 csproj 文件中设置:(

【讨论】：

【解决方案18】：

在尝试了此处发布的所有其他建议后，我发现解决方案是从 .csproj 文件中删除以下部分：

  <ItemGroup>
    <Service Include="{808359B6-6B82-4DF5-91FF-3FCBEEBAD811}" />
  </ItemGroup>

显然，来自原始项目的这项服务（在本地机器上不可用）正在停止整个构建过程，即使它对于编译不是必需的。

【讨论】：

【解决方案19】：

向我的项目添加新平台后，我遇到了这个问题。在我的情况下 .csproj 文件在 Perforce 源代码控制下并且是只读的。我检查了它，但 VS 直到我重新启动它才发现变化。

【讨论】：

【解决方案20】：

我在 Xamarin 项目中遇到过类似问题。这可能是罕见的情况，但以防其他人遇到问题。我的项目结构如下所示

xamarin.Android 项目有来自 xamarin.android.library 项目的引用。
我使用 android.library 项目中的一些代码创建了一个插件。
现在问题来了。如果您在 xamarin.android 库项目上添加项目引用或 nuget 安装。你会得到这个错误。开发人员假设代码在 Android.Library 项目中，我必须在这个项目中引用新插件。不！
您必须在主 Android 项目上添加一个引用。因为插件->库->主项目输出没有产生。

【讨论】：

【解决方案21】：

与 Philip Atz 类似，我的 .csproj 文件顶部有以下行。

<Import Project="$(MSBuildExtensionsPath)\Xamarin\iOS\Xamarin.iOS.CSharp.targets" />

将其进一步向下移动为我解决了这个问题。

【讨论】：

【解决方案22】：

对我来说，错误不是由一个晦涩的问题引起的，其他人似乎就是这种情况，例如this answer。就我而言，错误消息非常准确地描述了问题所在。据说我正在尝试为特定的构建配置和目标平台构建，但我的项目属性文件中没有定义配置/平台的组合。所以我探索了两种选择：

根据this answer修改项目文件以支持给定的目标平台
根据项目属性将构建的目标平台修改为现有支持的配置之一

两者都在使问题消失的意义上起作用。但第二个对我来说是正确的。我遇到的问题如下：

在 VS 中，我有一个 x86 的目标平台，并且项目文件中有一个 PropertyGroup，所以一切正常。
但是当我尝试从命令行构建时，使用MSBuild.exe 默认目标平台是“任何 cpu”，除非明确指定为命令行参数。

因此，在我的情况下，由于我想以 x86 为目标，因此我的解决方法是在命令行上明确告诉 MSBuild 为 x86 平台构建，根据 this answer。

引用这个答案：

C:\Windows\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe my.sln /t:build /p:Configuration=Release;Platform=x86

注意重要部分：

;Platform=x86

【讨论】：