La propiedad OutputPath no está establecida para este proyecto

120

Cuando intento compilar mi proyecto desde el modo de depuración x86 en Visual Studio 2008, obtengo este error. Cuando miré el grupo de propiedades del proyecto que se quejó, veo que la ruta de salida está configurada.

Aquí está la sección del grupo de propiedades para ese archivo .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>

¿Alguien puede arrojar luz sobre esto?

NOTA: Cuando compilé esta depuración y cualquier CPU funcionó.

ACTUALIZADO: Error 1 La propiedad OutputPath no está establecida para este proyecto. Verifique para asegurarse de haber especificado una combinación de Configuración / Plataforma válida. Configuración = 'Depuración' Plataforma = 'x86'

Amzath
fuente
Ok, ¿y qué configuración y plataforma usas? ¿Debug + x86 o algo más?
Ondrej Tucny
Sí VS administrador de configuración, elijo debug + x86
Amzath
@DmitryShkuropatsky mensaje de error actualizado
Amzath
1
Parece correcto. ¿Hay otro proyecto en la solución que pueda causar el error?
Dmitry Shkuropatsky
@DmitryShkuropatsky, tienes razón, fue otro proyecto que tuvo problemas. Pero VS se quejó del proyecto que se está compilando
Amzath

Respuestas:

214

Tuve exactamente el mismo error después de agregar una nueva configuración a través de ConfigurationManager en Visual Studio.

Resultó que cuando se agregó la configuración de 'Producción' para toda la solución (y cada proyecto), el elemento OutputPath no se agregó a los archivos .csproj.

Para solucionarlo, fui a la pestaña Compilar en las propiedades del proyecto, cambié OutputPath de \bin\Production\a \bin\Production(final eliminado \) y guardé los cambios. Esta creación forzada del elemento OutputPath en el archivo .csproj y el proyecto se ha construido correctamente.

Me suena como una falla.

Roman Gudkov
fuente
7
Buena captura de este mercurial error. Nunca hubiera imaginado que una sola barra podría hacer una gran diferencia. Tener una insignia de buena respuesta.
ouflak
8
En mi caso, la creación de un archivo de proyecto, la diferencia entre any cpuy anycpufue el problema, pero su publicación me ayudó a ver eso.
Joshua Drake
2
Gracias Roman, me salvaste el día ... ¡si tan solo pudiera votar tu respuesta 100 veces! :)
Martin
2
Acabo de encontrar esto en VS 2017 v15.6.6, tocino guardado, ¡gracias!
Angrist
1
@Joshua Drake, este es un tema importante al usar VSTS. Visual Studio online usa 'cualquier CPU', mientras que Visual Studio local usa 'anycpy'. Importante para crear scripts.
FrankyHollywood
27

Puede ver este error en VS 2008 si tiene un proyecto en su solución que hace referencia a un ensamblado que no se puede encontrar. Esto podría suceder si el ensamblaje proviene de otro proyecto que no es parte de su solución, pero debería serlo. En este caso, simplemente agregar el proyecto correcto a la solución lo resolverá.

Consulte la sección Referencias de cada proyecto de su solución. Si alguno de ellos tiene una referencia con una x roja al lado, entonces ha encontrado su problema. La solución no puede encontrar esa referencia de ensamblado.

El mensaje de error es un poco confuso, pero lo he visto muchas veces.

dblood
fuente
2
En mi caso fue una "advertencia amarilla"
AXMIM
26

Si está utilizando WiX, mire esto (hay un error) http://www.cnblogs.com/xixifusigao/archive/2012/03/20/2407651.html

A veces, las nuevas configuraciones de compilación se agregan al .wixprojarchivo más abajo en el archivo, es decir, se separan de las definiciones de configuración del hermano por otros elementos XML no relacionados.

Simplemente edite el .wixprojarchivo para que todas las <PropertyGroup>secciones que definen sus configuraciones de compilación estén adyacentes entre sí. (Para editar el .wixprojen VS2013, haga clic con el botón derecho en el proyecto en el Explorador de soluciones, Descargar proyecto, haga clic con el botón derecho nuevamente-> Editar YourProject.wixproj. Vuelva a cargar después de editar el archivo).

Jorge
fuente
1
gracias, esto me lo arregló. Tuve un comportamiento muy extraño cuanto más configuraciones agregué al proyecto. Tan pronto como limpié el archivo del proyecto, todo funcionó bien. (¿Este error se informó por primera vez en 2012?
Genial
Gracias, esto también me
solucionó
15

Esto me sucedió porque había movido la siguiente línea cerca del comienzo del archivo .csproj:

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

Debe colocarse después de los PropertyGroups que definen su Configuración | Plataforma.

Philip Atz
fuente
11

El error que se muestra en Visual Studio para el proyecto (digamos A) no tiene problemas. Cuando miré la ventana de salida para la construcción línea por línea para cada proyecto, vi que se estaba quejando de otro proyecto (B) que se había denominado ensamblado en el proyecto A. Proyecto B agregado a la solución. Pero no se había mencionado en el proyecto A como referencia del proyecto, sino como referencia de ensamblaje desde una ubicación diferente. Esa ubicación contiene el ensamblado que se compiló para Platform AnyCpu. Luego eliminé la referencia de ensamblaje del proyecto A y agregué el proyecto B como referencia. Comenzó a compilarse. Sin embargo, no estoy seguro de cómo funcionó esta solución.

Amzath
fuente
15
Deffo inténtelo con \ p: Platform = "AnyCPU" en lugar de \ p: Platform = "Any CPU". ¡Eso funcionó para mí! ¡Estuve mirando esto durante años!
Lee Englestone
AnyCPU (sin el espacio) también funcionó para mí. Gracias Lee.
willem
1
Encontré el error mientras ejecutaba un proceso de compilación en TFS 2017, después de cambiar la "Ruta a la solución o paquetes.config" de .sln a .vbproj. Cambiar BuildPlatform a AnyCPU también funcionó para mí. Consulte la nota en "Plataforma" aquí: docs.microsoft.com/en-us/vsts/build-release/tasks/build/…
Mr.Zzyzzx
2
En mi caso, al iniciar la compilación desde TFS, "any cpu"era el valor predeterminado para BuildPlatform. Cambiar para "AnyCPU"resolver el problema.
XouDo
Estamos en 2020: AnyCPU vs Any CPU sigue siendo un problema. Estoy usando VS2019 y todavía obtengo esto en nuevos proyectos. MS, ¿por qué castiga a la comunidad de desarrolladores?
Christian
9

Encontré el mismo error, pero el problema resultó ser porque había creado una nueva configuración en mi solución que no existía en los ensamblados referenciados de otra solución.

Esto se puede resolver abriendo la solución relacionada y agregando también la nueva configuración.

Esta publicación me dio la idea de verificar los ensamblados referenciados después de haber confirmado que todos los proyectos dentro de mi solución tenían la configuración correcta:

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

BK
fuente
7

tuvo este problema como resultado de Azure DevOps después de configurar la compilación .csproj en lugar de .sln en Build Pipeline.

La solución para mí: edite .csproj del proyecto afectado, luego copie todo su

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

Node, péguelo y luego cambie la primera línea de la siguiente manera:

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

La razón es que en mi caso el error decía

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

Por qué Azure quiere usar "cualquier cpu" en lugar del predeterminado "AnyCpu" es un misterio para mí, pero este truco funciona.

Jens Caasen
fuente
Siguiendo su idea, descubrí que en mi caso no necesitaba hacer cambios en el proyecto, sino que en mi paso de Visual Studio Build en DevOps configuré el campo de configuración para usar la variable con el valor AnyCpu.
donatasj87
@ donatasj87 ¿le importaría publicar el valor total de este campo, por favor?
Jay
1
El valor total es exactamente el mismo, esto también debería funcionar en la compilación de TFS. Solo necesita coincidir con el valor que está configurado en su archivo .csproj. Se puede ver en esta imagen: pasteboard.co/JbdvBT5.png
donatasj87
4

Tuve el mismo error, así que miré la configuración del proyecto y allí, en la sección "Construir", está la opción "Crear ruta de salida". Y el valor estaba vacío. Así que llené el valor "bin \" y desapareció el error. Resolvió mi problema.

Lukas Dvorak
fuente
3

Yo tengo:

  1. Haga clic derecho en el proyecto con problema -> Descargar proyecto
  2. Haga clic derecho en el proyecto y elija Editar * .csproj
  3. Copie y pegue la configuración de la configuración existente que funciona con un nombre específico y una plataforma de orientación (tenía 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>
  4. Proyecto de clic derecho -> Recargar proyecto
  5. Reconstruir proyecto / solución
Janis S.
fuente
3

Si obtiene este error solo cuando intenta compilar su proyecto desde la línea de comandos usando MSBuild (como en mi caso), la solución es pasar la ruta de salida manualmente a MSBuild con un argumento como /p:OutputPath=MyFolder.

anión
fuente
2

Otra posibilidad loca: si sigue un arreglo simple de control de fuente de poner Branch \ Main, Main y Release uno al lado del otro y de alguna manera termina agregando un proyecto existente desde Main en lugar de Branch \ Main (asumiendo que su solución de trabajo es Branch \ Main), es posible que vea este error.

La solución es simple: ¡haga referencia al proyecto correcto!

Keith Hoffman
fuente
2

Encontré este problema al agregar un proyecto a una solución y luego hacer referencia a otro proyecto en la misma solución: obtuve el ícono de advertencia amarillo sobre la referencia, observe que la ruta estaba vacía.

La solución fue similar a lo que sugirió @Amzath, mis proyectos se estaban compilando con diferentes marcos de destino, por ejemplo. .NET 4.0 frente a 4.5.

StuTheDog
fuente
2

En mi caso, la dirección integrada de mi aplicación se configuró en otra computadora que estaba apagada, así que la encendí y reinicié VS y el problema se resolvió.

Jesús Manuel
fuente
2

Otra causa: agrega una referencia de proyecto del proyecto A al proyecto B en la solución X. Sin embargo, la solución Y que ya contiene el proyecto A ahora está rota, hasta que también agrega el proyecto B a la solución Y.

David White
fuente
2

Tuve el mismo problema después de agregar nuevas configuraciones y eliminar las configuraciones de "depuración" y "liberación". En mi caso, estaba usando un archivo cmd para ejecutar el proceso de compilación y publicación, pero se produjo el mismo error. La solución para mí: en el archivo csproj lo siguiente:

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

estaba configurando la Configuración en "Depurar" si no especificaba una explícita. Después de cambiar el valor del nodo de "depuración" a mi configuración personalizada, todo funcionó sin problemas. Espero que esto también ayude a quien esté leyendo esto :)

MihaiB
fuente
Los detalles de esta solución se mencionan en esta publicación del foro. social.msdn.microsoft.com/Forums/vstudio/en-US/…
Sunny Tambi
2

Tuve el mismo problema, simplemente edite el .wixproj para que todos los <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... >elementos estén uno al lado del otro.

Eso resolvió mi problema

Sharon
fuente
1

El proyecto de WiX que estaba usando estaba fijo en el administrador de configuración para x64todos los ámbitos. Al realizar el proyecto de Acción personalizada para la solución, todo lo predeterminado estaba x86dentro del .csprojarchivo. Así que descargué el proyecto, lo edité cambiando todo x86a x64, guardé, volví a cargar y estaba listo para continuar.

No entiendo por qué tuve que hacer esto. El administrador de configuración estaba configurado para compilarse como x64, pero simplemente no se configuraba en el csprojarchivo :(

kayleeFrye_onDeck
fuente
0

Después de probar todas las otras sugerencias publicadas aquí, descubrí que la solución para mí era eliminar la siguiente sección del .csprojarchivo:

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

Aparentemente, este servicio del proyecto original (no disponible en la máquina local) estaba deteniendo todo el proceso de compilación, aunque no era esencial para la compilación.

Salsa especial
fuente
0

Tuve este problema después de agregar una nueva plataforma a mi proyecto. En mi caso, el archivo .csproj estaba bajo el control de fuente de Perforce y era de solo lectura. Lo comprobé, pero VS no captó el cambio hasta que lo reinicié.

Flot2011
fuente
0

Tuve un problema similar en un proyecto Xamarin. Tal vez sea un caso raro, pero en caso de que alguien más tenga el problema. la estructura de mi proyecto era la siguiente

  • El proyecto xamarin.Android tenía una referencia del proyecto xamarin.android.library.
  • Creé un complemento usando un código del proyecto android.library.
  • Ahora aquí está el problema. si agrega la referencia del proyecto o la instalación de nuget en el proyecto de biblioteca xamarin.android. Obtendrá este error. Los desarrolladores asumen que el código estaba dentro del proyecto Android.Library y debo hacer referencia al nuevo complemento en este proyecto. ¡NO!
  • debe agregar una referencia en el proyecto principal de Android. porque el complemento-> biblioteca-> salida del proyecto principal no se produce.
batmaci
fuente