2012-01-31 21 views
61

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

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

Puede alguien arrojar la luz sobre esto?

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

ACTUALIZADO: Error 1 La propiedad OutputPath no está configurada para este proyecto. Verifique que haya especificado una combinación de Configuración/Plataforma válida. Configuración = 'Depurar' Plataforma = 'x86'

+0

Ok, ¿qué configuración y plataforma usa? ¿Depura + x86 o algo más? –

+0

Sí Administrador de configuración de VS elijo debug + x86 – Amzath

+0

¿Cuál es el mensaje de error? –

Respuesta

7

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 quejaba de otro proyecto (B) que se había denominado ensamblaje en el proyecto A. Proyecto B agregado a la solución. Pero no se ha referido en el proyecto A como referencia de proyecto en su lugar como referencia de ensamblado desde diferente ubicación. Esa ubicación contiene el ensamblado que compiló para Platform AnyCpu. Luego eliminé la referencia de ensamblaje del proyecto A y agregué el proyecto B como referencia. Comenzó a compilar. No estoy seguro de cómo funcionó esta solución.

+11

Deffo try it con \ p: Platform = "AnyCPU" en lugar de \ p: Platform = "Cualquier CPU". ¡Eso funcionó de mí! ¡Estaba mirando esto durante años! –

+0

AnyCPU (Sin el espacio) también funcionó f o yo. Gracias Lee. – willem

+0

Encontré el error al ejecutar un proceso de compilación en TFS 2017, después de cambiar la "Ruta a la solución o packages.config" de .sln a a .vbproj. Cambiar BuildPlatform a AnyCPU también funcionó para mí. Consulte la nota debajo de "Plataforma" aquí: https://docs.microsoft.com/en-us/vsts/build-release/tasks/build/visual-studio-build –

26

Puede ver este error en VS 2008 si tiene un proyecto en su solución que hace referencia a un ensamblaje que no se puede encontrar. Esto podría suceder si el ensamblaje proviene de otro proyecto que no forma 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 de Referencias de cada proyecto en su solución. Si alguno de ellos tiene una referencia con una x roja al lado, entonces ha encontrado su problema. Esa referencia de ensamblaje no puede ser encontrada por la solución.

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

+1

En mi caso fue una "advertencia amarilla" – AXMIM

2

Otra opción loca: Si sigue una disposición de control de fuente simple de poner Branch \ Main, Main y Release al lado el uno del otro y de alguna manera termina agregando un proyecto existente desde Main en vez de Branch \ Main (asumiendo la solución de trabajo es Branch \ Main), es posible que vea este error.

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

8

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 a los que se hacía referencia desde otra solución.

Esto puede resolverse abriendo la solución relacionada y añadiéndole también la nueva configuración.

Este post me dio la idea para comprobar los ensamblados de referencia después de que ya había confirmado que todos los proyectos de mi solución tenía la configuración correcta:

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

+0

gracias me ayudó :) – MikroDel

2

me encontré con este problema al añadir a un proyecto una solución que luego hace referencia a otro proyecto en la misma solución-- obtuvo el icono 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 objetivos, por ej. .NET 4.0 vs 4.5.

3

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

2

En mi caso, la dirección de compilación de mi aplicación estaba configurada en otra computadora que estaba apagada, así que la encendí y reinicie VS y el problema fue resuelto.

15

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

veces nuevas configuraciones de construcción se añaden al archivo .wixproj más abajo en el archivo, es decir, separados de sus definiciones hermano de configuración por otra elementos XML no relacionados.

Simplemente edite el archivo .wixproj para que todas las secciones <PropertyGroup> que definen sus configuraciones de compilación estén adyacentes entre sí. (Para editar .wixproj en VS2013 haga clic derecho en el proyecto en el Explorador de soluciones, descargue proyectos, haga clic derecho nuevamente-> Edite YourProject.wixproj. Recargue después de editar el archivo.)

+0

gracias, esto lo arregló para mí. Tenía un comportamiento extraño, 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? Gran ...) – Kirschi

1

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

2

Tuve el mismo problema después de haber agregado nuevas configuraciones y eliminado el " configuración de depuración "y" liberación ". En mi caso, estaba usando un archivo cmd para ejecutar el proceso de creación y publicación, pero se lanzó el mismo error. La solución para mí: En el archivo csproj lo siguiente:

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

estaba poniendo la configuración de "depuración" si no se ha especificado una explícita. Después de cambiar el valor del nodo de "depurar" a mi configuración personalizada, todo funcionó sin problemas. Espero que esto también ayude a cualquiera que esté leyendo esto :)

+0

Los detalles de esta solución se mencionan en esta publicación del foro. https://social.msdn.microsoft.com/Forums/vstudio/en-US/87b8aba4-9c61-4cfa-88f3-6236ee813582/msbuild-package-fails-with-outputpath-property-is-not-set- error? forum = msbuild –

62

Tenía exactamente el mismo error después de agregar una nueva configuración a través de ConfigurationManager en VisualStudio.

Se completó 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 solucionar esto, fui a un separador Crear de propiedades del proyecto, cambió OutputPath de \bin\Production\ a \bin\Production (suprimido detrás \) y se guardan los cambios. Esto forzó la creación del elemento OutputPath en el archivo csproj y el proyecto se creó correctamente.

Suena como un problema para mí.

+4

Buena captura en este error mercurial. Nunca hubiera adivinado que una sola barra podría marcar una gran diferencia. Tener una insignia de Buena respuesta. – ouflak

+4

En mi caso, al compilar un archivo proj, la diferencia entre 'cualquier CPU 'y' anycpu' era el problema, pero su publicación me ayudó a ver eso. –

+0

Gracias, Romano, salvaste mi día ... ¡si tan solo pudiera votarte tu respuesta 100 veces! :) – Martin

0

que tenían el mismo problema, Basta con modificar el .wixproj tener todos los elementos <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... > estar al lado del otro.

que resolvió mi problema

1

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

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

tiene que ser colocado después de los PropertyGroups que definen su Configuración | Plataforma.

0

El proyecto de WiX que estaba utilizando estaba fijo en el administrador de configuración para x64 en general. Al realizar el proyecto de acción personalizada para la solución, de manera predeterminada todo en x86 dentro del archivo .csproj. Así que descargué el proyecto, lo edité cambiando todos los x86 a x64, lo guardé, volví a cargar, y estaba listo para continuar.

No entiendo por qué tuve que hacer esto. El administrador de configuración se configuró para que se construya como x64, pero simplemente no se establece en el archivo csproj :(

Cuestiones relacionadas