Error de compilación VS2013 externo "error MSB4019: no se encontró el proyecto <path> importado"


201

Estoy creando un proyecto a través de la línea de comandos y no dentro de Visual Studio 2013. Tenga en cuenta que había actualizado mi proyecto de Visual Studio 2012 a 2013. El proyecto se construye bien dentro del IDE. Además, desinstalé completamente VS2012 primero, reinicié e instalé VS2013. La única versión de Visual Studio que tengo es 2013 Ultimate.

ValidateProjects:
    39>path_to_project.csproj(245,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    39>Done Building Project "path_to_project.csproj" (Clean target(s)) -- FAILED.

Aquí están las dos líneas en cuestión:

<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

La segunda línea original era v10.0, pero la cambié manualmente a v12.0.

$ (VSToolsPath) se alarga de lo que veo a la carpeta v11.0 (VS2012), que obviamente ya no existe. La ruta debería haber sido a v12.0.

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\

Intenté especificar VSToolsPath en la tabla de variables de entorno de mi sistema, pero la utilidad de compilación externa todavía usa v11.0. Traté de buscar a través del registro y eso no encontró nada.

Lamentablemente, no veo ninguna manera fácil de obtener la línea de comando exacta utilizada. Yo uso una herramienta de construcción.

Pensamientos?



En mi caso, tuve que especificar la VisualStudioVersion correcta en el evento de compilación que se estaba compilando con el destino WebPublish.
user145400

Respuestas:


250

Tuve el mismo problema y encuentro una solución más fácil

Se debe a que Vs2012 agregó lo siguiente al archivo csproj:

<PropertyGroup>
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>

Puede eliminar esa parte de forma segura y su solución se construirá.

Como Sielu señaló, debe asegurarse de que el archivo .proj comience de lo <Project ToolsVersion="12"contrario la próxima vez que abra el proyecto con Visual Studio 2010, agregará nuevamente el nodo eliminado.

De lo contrario, si necesita usar webdeploy o un servidor de compilación, la solución anterior no funcionará, pero puede especificar la VisualStudioVersionpropiedad en su script de compilación:

msbuild myproject.csproj /p:VisualStudioVersion=12.0

o edite su definición de compilación:

edite la definición de compilación para especificar la propiedad <code> VisualStudioVersion </code>


1
Recibí el error usando msbuild desde el símbolo del sistema. Eliminar esta parte del archivo del proyecto resolvió el problema.
Peter Hedberg

77
Utilicé esta respuesta y funcionó solo si me aseguré de que mi archivo * proj comenzara con <Project ToolsVersion = "12" Antes de tener <Project ToolsVersion = "4" y cada vez que abría el proyecto en VS agregaba los dos nodos nuevamente (es decir, volvió a migrar el proyecto a la última versión).
Sielu

3
@giammin, ya encontré la solución. NO elimine la sección de su archivo de proyecto. Establezca la versión de herramientas correcta en su definición de compilación. Esto es muy fácil de hacer. Abra su definición de compilación y vaya a la página "Proceso". Luego, bajo el grupo "3. Avanzado", tiene una propiedad llamada "Argumentos MSBuild". Coloque el parámetro allí con la siguiente sintaxis "/p:VisualStudioVersion=12.0". Por supuesto sin las comillas. Si tiene más parámetros, sepárelos con un espacio y no con una coma. La configuración que sugirió eliminar es utilizada por otras partes de Visual Studio en su proceso de construcción ...
Ralph Jansen

9
Eliminar esa línea parece romper la implementación web
Colin Pear

44
Tuve el mismo problema que se resolvió utilizando la propiedad /p:VisualStudioVersion=12.0 como se recomienda anteriormente. Gracias
Randeep

70

También tuve esto y puedes solucionarlo configurando la versión de herramientas en tu definición de compilación.

Esto es muy fácil de hacer. Abra su definición de compilación y vaya a la página " Proceso ". Luego, bajo el grupo " 3. Avanzado ", tiene una propiedad llamada " Argumentos MSBuild ". Coloque el parámetro allí con la siguiente sintaxis

/p:VisualStudioVersion=12.0 

Si tiene más parámetros, sepárelos con un espacio y no con una coma.


1
Acabamos de completar una actualización de TFS 2005 a TFS 2013 y este fue nuestro último obstáculo. Esto definitivamente funcionó para nosotros y me salvó de arrancarme el cabello. ¡Muchas gracias! +1.
Simon Whitehead

2
Este artículo de Sayed Ibrahim Hashimi describe el problema en Visual Studio 2010/2012. Una compilación de línea de comando utiliza el formato de archivo sln versión -1 como VisualStudioVersion. Puede anular este valor desde la línea de comandos como describe Ralph, o como una propiedad de la tarea MSBuild desde un script de compilación. Tuve el mismo problema con Visual Studio 2013, y anular VisualStudioVersion resolvió el problema.
mcdon

1
Esto funcionó para nosotros también. También consideramos modificar la plantilla de compilación en sí, que se describe aquí , que podría ser una mejor opción si tiene docenas de definiciones de compilación.
JamesQMurphy

Esto funcionó para mí. Eliminé en los archivos csproj cualquier referencia a visualstudioversion y luego agregué ese argumento
msbuild

51

Esto está estrechamente relacionado, pero puede o no solucionar el problema específico de los OP. En mi caso, estaba tratando de automatizar la implementación de un sitio de Azure con VS2013. Sin embargo, construir e implementar a través de VS funciona, utilizando MSBuild mostró un error similar en torno a los "objetivos". Resulta que MSBuild es diferente bajo VS2013, y ahora es parte de VS y no del .Net Framework (ver http://timrayburn.net/blog/visual-studio-2013-and-msbuild/ ). Básicamente, use la versión correcta de MSBuild:

ANTIGUO, VS2012

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe

NUEVO VS2013

C:\Program Files (x86)\MSBuild\12.0\bin\msbuild.exe

Más nuevo, VS2015

C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe

Más nuevo aún, VS2017 (no se está probando completamente, pero se descubrió; han cambiado un poco las cosas)

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\msbuild.exe

Esto me lo arregló. Además, una respuesta similar para una pregunta similar aquí: stackoverflow.com/a/19826448/61569
Anthony F

22

Acabo de recibir una respuesta de Kinook, quien me dio un enlace :

Básicamente, necesito llamar a los siguientes antes de bulding. Supongo que Visual Studio 2013 no registra automáticamente el entorno primero, pero 2012 sí, o lo hice y lo olvidé.

call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86

Con suerte, esta publicación ayuda a alguien más.


¡Muchas gracias, esto solucionó mi problema en la construcción de nodejs node-gypla Cpp default.propsque no se encontró nada +1
Pogrindis

21

La solución de giammin es parcialmente incorrecta. Usted NO DEBE eliminar todo ese PropertyGroup de su solución. Si lo hace, la función "DeployTarget = Package" de MSBuild dejará de funcionar. Esta característica se basa en la configuración de "VSToolsPath" .

<PropertyGroup>
  <!-- VisualStudioVersion is incompatible with later versions of Visual Studio.  Removing. -->
  <!-- <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> -->
  <!-- VSToolsPath is required by MSBuild for features like "DeployTarget=Package" -->
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
...
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

10

Tuve este problema para nuestros objetivos FSharp (FSharpTargetsPath estaba vacío).

Muchas de las rutas se crean con referencia a la versión VS.

Por varias razones, nuestra compilación se ejecuta con privilegios del sistema, y ​​la variable de entorno "VisualStudioVersion" solo fue establecida (por el instalador VS 2013) en el nivel de "usuario", lo cual es bastante justo.

Asegúrese de que la " VisualStudioVersion" variable de entorno esté establecida en " 12.0" en el nivel (Sistema o Usuario) en el que se está ejecutando.


55
Este es probablemente un escenario común cuando se ejecuta un servidor de compilación (como CruiseControl o TeamCity), donde el servicio se ejecuta bajo una cuenta de servicio en particular que puede que ni siquiera tenga permisos de escritorio interactivos. Este consejo me resolvió el problema (VS 2013 instalado en una instalación limpia de Server 2008 R2, con CruiseControl.NET)
David Keaveny

¿Dónde puedo ver mi "VisualStudioVersion"?
WEFX

@WEFX vea las variables de entorno seleccionando Systemdesde el Panel de control, luego seleccione Advanced system settingsy finalmente haga clicEnvironment Variables
Scott

6

Ejecutar esto en la línea de comandos también solucionará el problema. SETX VisualStudioVersion "12.0"


Esto funcionó para mí y era preferible a modificar el archivo del proyecto.
Sean

4

Si migra Visual Studio 2012 a 2013, abra el archivo de proyecto * .csprorj con edior.
y marque el elemento ToolsVersion de la etiqueta 'Proyecto'.

Ese es el valor 4.0
Usted llega a 12.0

  • De

    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="4.0"
  • A

    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="12.0"

O bien, si crea con msbuild, simplemente especifique la propiedad VisualStudioVersion

msbuild /p:VisualStudioVersion=12.0


1
ToolsVersion no debe ser la única variable para corregir este mensaje de error porque vi un proyecto con ToolsVersion que no se pudo compilar correctamente.
Patrick Desjardins

2

Estaba usando una utilidad de compilación externa. Piensa en algo así como hormigas, si entiendo el producto correctamente, solo una versión comercial. Tuve que contactar al fabricante para obtener la respuesta.

Como resultado, hay una macro global en el proyecto, DEVSTUDIO_NET_DIR. Tuve que cambiar el camino a .Net allí. Enumeran varias versiones de estudio visual como "Acciones", que a través de mí, pero todos los caminos conducen a esa variable global detrás de escena. Lo mencionaría como un defecto en el producto, si me saliera con la mía, a menos que me falte algo en mi entendimiento. Corregir la ruta allí solucionó el problema de compilación.


2

Tengo instalado Visual Studio 2013. Esto funcionó para mí:

<PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' != ''">12.0</VisualStudioVersion>`
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>

Así que he cambiado la condición de ==a !=y el valor de 10.0a 12.0.


2

Tuve un problema similar. Todas las soluciones propuestas se solucionan para este problema pero no resuelven la fuente de error. La solución @giammin no se debe aplicar si está utilizando el servidor de compilación tfs, ya que se acaba de bloquear la funcionalidad de publicación. Solución @ cat5dev: resuelve el problema pero no resuelve la fuente del mismo.

Estoy casi seguro de que está utilizando la plantilla de proceso de compilación para VS2012, ya que ReleaseDefaultTemplate.11.1.xaml or DefaultTemplate.11.1.xaml estas plantillas de compilación se han creado para VS2012 y $ (VisualStudioVersion) configurado en 11.0

Usted debe utilizar la plantilla proceso de construcción de VS2013 ReleaseTfvcTemplate.12.xaml or TfvcTemplate.12.xaml que ha fijado $ (VisualStudioVersion) a 12,0

Esto funciona sin cambios en el archivo del proyecto.


2

También tuve el mismo error ... hice esto para solucionarlo

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" />

cambiar a

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

Y ya está hecho.


2

En mi caso, solo comento debajo de la línea abriendo el archivo .csproj e hice el truco

.<!-- <Import Project="..\PRPJECTNAME.targets" /> -->

Mi problema puede ser diferente, pero me arrastran aquí, pero esto puede ayudar a alguien.

Elegí un solo proyecto web de mi solución e intenté abrirlo como un proyecto independiente que estaba causando problemas, después de lo anterior, puedo resolver el problema.


2

Use la versión correcta de MSBuild. Establezca la variable de entorno en:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin

Esto también funcionará para proyectos VS 2019

Anteriormente lo estábamos configurando en C:\Windows\Microsoft.NET\Framework\v4.0.30319


Usé "C: \ Archivos de programa (x86) \ Microsoft Visual Studio \ 2019 \ Enterprise \ MSBuild \ Current \ Bin \ MSBuild.exe" en lugar de "C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ MSBuild. exe" y su trabajado
ELKALAKHI Mohammed

Sí, estoy usando un proyecto SSDT (.sqlproj), con VisualStudioVersion = 14.0 en el archivo del proyecto. Instalé core 3.1, que establece mis valores para los objetivos de Dios solo sabe dónde. ¡Usar el msbuild en la carpeta que sugirió funcionó de maravilla!
Matthew Beck

1

En mi caso, el entorno de desarrollo es VS2013 y estoy usando TFS 2010. Build estaba dirigido a .NET 4.5.1. Estaba configurando la compilación automática para CI. cada vez que intentaba las soluciones mencionadas anteriormente, como eliminar el grupo de propiedades por completo o reemplazar algunas líneas, etc., mi compilación solía ocurrir en TFS, pero mi publicación en azul solía fallar con 'MSDeploy' o, a veces, algún error diferente. No pude lograr ambas cosas simultáneamente.

Así que finalmente tuve que pasar el argumento de MSBuild para resolver el problema.

Ir a Editar definición de compilación> Proceso> 3. Avanzado> Argumentos de MSBuild (establecido en) /p:VisualStudioVersion=12.0

Funcionó para mi.


1

Debe copiar las aplicaciones web de carpeta de C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v12.0 \ a C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \


O copie solo el archivo Microsoft.WebApplication.targets desde una ubicación donde está instalado Visual Studio 2013.
ThatBlairGuy

0

usted encontrará

C:\Program Files  (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets 

en el archivo csproj para el que aparece este error. Simplemente elimine esto de csproj y luego compile.


0

Solo se necesita hacer una cosa para resolver el problema: actualizar TeamCity a la versión 8.1.xo superior porque el soporte para Visual Studio 2012/2013 y MSBuild Tools 2013 solo se introdujo en TeamCity 8.1. Una vez que haya actualizado su TeamCity, modifique la configuración de Versión de MSBuild Tools en su paso de compilación en consecuencia y el problema desaparecerá. Para obtener más información, lea aquí: http://blog.turlov.com/2014/07/upgrade-teamcity-to-enable-support-for.html


0

Yo: nada ayudaba a cambiar el valor v11.0 de la variable VisualStudioVersion a v10.0. Cambiar la variable en el archivo .csproj no lo hizo. Configurarlo a través de la solicitud de comando no lo hizo. Etc ...

Terminé copiando mi carpeta local de esa versión específica (v11.0) en mi servidor de compilación.


0

Había probado todas las soluciones anteriores y todavía no tuve suerte. Había escuchado a personas instalar Visual Studio en sus servidores de compilación para solucionarlo, pero solo tenía 5 gb de espacios libres, así que simplemente copié C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio en mi servidor de compilación y lo llamé un día . Comenzó a trabajar después de eso, usando Team City 9.xy Visual Studio 2013.


0

Basado en TFS 2015 Build Server

Si contrarrestas este error ... Error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

Abra el .csprojarchivo del proyecto nombrado en el mensaje de error y comente la sección a continuación

<!-- <PropertyGroup> --> <!-- <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> --> <!-- <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath> --> <!-- </PropertyGroup> -->


0

Recibí este error cuando instalo algunos componentes VS. Lamentablemente, ninguna de estas respuestas no me ayudó. Uso TFS para el desarrollo de comandos y no tengo permisos para editar la definición de compilación. Resolví este problema eliminando variables de entorno que llamaban VS110COMNTOOLSy VS120COMNTOOLS. Creo que se instaló con mis componentes VS.


0

Descubrí que me faltaba la carpeta WebApplications en mi PC local, no se instaló con Visual Studio 2017 como lo hacía cuando estaba usando 2012.


0

En mi caso estaba usando la versión incorrecta de MSBuild.exe .

La versión que necesita usar depende de la versión de Visual Studio que utilizó para crear su proyecto. En mi caso, necesitaba 14.0 (después de haber usado Visual Studio 2015).

Esto se encontró en:

C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe

Puedes mirar debajo:

C:\Program Files (x86)\MSBuild

Para encontrar otras versiones.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.