c# español - Error de compilación VS2013 externo "error MSB4019:no se encontró el proyecto importado<ruta>"




visual asp (20)

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 esta hecho

Estoy creando un proyecto a través de la línea de comandos y no dentro de Visual Studio 2013. Nota, había actualizado mi proyecto de Visual Studio 2012 a 2013. El proyecto se desarrolla 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 extiende desde lo que veo a la carpeta v11.0 (VS2012), que obviamente ya no está allí. El camino debería haber sido v12.0.

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

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

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

¿Pensamientos?


Debe copiar la aplicación Web de C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v12.0 \ a C: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.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 quite esto de csproj y luego compile.


Descubrí que faltaba la carpeta de aplicaciones web en mi PC local, no la instalé con Visual Studio 2017 como la que tenía cuando estaba usando 2012.


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.0 a 12.0 .


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

Ese es el valor 4.0
Lo haces a 12.0

  • Desde

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

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

O si creas con msbuild, simplemente especifica la propiedad VisualStudioVersion

msbuild /p:VisualStudioVersion=12.0


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 estoy arrastrado aquí, pero esto puede ayudar a alguien.

Escogí un solo proyecto web de mi solución e intenté abrirlo como un proyecto independiente que estaba generando problemas, después de todo lo anterior, puedo resolverlo.


Basado en TFS 2015 Build Server

Si contrarresta 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. ... 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 archivo .csproj del proyecto mencionado en el mensaje de error y comente la siguiente sección

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


La solución de giammin es parcialmente incorrecta. NO DEBE eliminar todo el Grupo de propiedades de su solución. Si lo hace, la característica "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)' != ''" />

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

Básicamente, necesito llamar a lo siguiente antes de la construcción. Supongo que Visual Studio 2013 no registra automáticamente el entorno primero, pero 2012 lo hizo, o lo hice y lo olvidé.

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

Con suerte, este post ayuda a alguien más.


He intentado todas las soluciones anteriores y todavía no he tenido suerte. Había escuchado a gente 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: \ Archivos de programa (x86) \ MSBuild \ Microsoft \ VisualStudio a mi servidor de compilación y lo llamé un día. . Comenzó a trabajar después de eso, utilizando Team City 9.xy Visual Studio 2013.


Tuve el mismo problema y encontré una solución más fácil.

Es debido a que Vs2012 agregue en el archivo csproj esta parte:

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

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

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

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

msbuild myproject.csproj /p:VisualStudioVersion=12.0

o edita la definición de tu compilación:


En mi caso, el entorno de desarrollo es VS2013 y estoy usando TFS 2010. La compilación fue dirigida 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 suceder en TFS, pero mi publicación de Azure solía fallar con 'MSDeploy' o, a veces, algún error diferente. No pude lograr ambos a la vez.

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 (configurados en) /p:VisualStudioVersion=12.0

Funcionó para mí.


Tuve un problema similar. Todas las soluciones propuestas son solo una solución para este problema, pero no están resolviendo 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 de la misma.

Estoy casi seguro de que está utilizando una plantilla de proceso de compilación para VS2012 como ReleaseDefaultTemplate.11.1.xaml or DefaultTemplate.11.1.xaml Estas plantillas de compilación se han creado para VS2012 y $ (VisualStudioVersion) configuradas en 11.0

Debe usar la plantilla de proceso de compilación para VS2013 ReleaseTfvcTemplate.12.xaml or TfvcTemplate.12.xaml que tiene $ (VisualStudioVersion) establecido en 12.0

Esto funciona sin ningún cambio en el archivo del proyecto.


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 (habiendo usado Visual Studio 2015).

Esto fue encontrado en:

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

Puedes mirar debajo:

C:\Program Files (x86)\MSBuild

Para buscar otras versiones.


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. Ponerlo a través de comando no lo hizo. Etc ...

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


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 utilizando VS2013. Sin embargo, la creación e implementación a través de VS Works, utilizando MSBuild mostró un error similar en torno a los "objetivos". Resulta que MSBuild es diferente en VS2013, y ahora es parte de VS y no de .Net Framework (consulte 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

Aún más reciente, VS2017 (no está probando completamente, pero lo descubrió: han movido las cosas un poco)

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

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

Muchas de las rutas se construyen 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 de VS 2013) en el nivel de "usuario", lo cual es justo.

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


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 la versión de MSBuild Tools en su paso de compilación 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


No necesitas que Windsor use DynamicProxy. Windsor utiliza DynamicProxy para sus propios fines, al igual que NHibernate, RhinoMocks, Moq u otras bibliotecas / aplicaciones / marcos por ahí. Si solo necesita AOP en tiempo de ejecución, sin contenedor IoC, use Caste DynamicProxy solo.

Está desarrollado activamente, el último prelanzamiento se lanzó hace 2 semanas, se espera el lanzamiento final (v2.5) este mes.

Nota: En versiones anteriores (hasta v2.2) DynamicProxy solía vivir en su propio ensamblaje Castle.DynamicProxy.dll. Más tarde se movió a Castle.Core.dll y ahora no se requiere ningún otro ensamblaje para usarlo. Source







c# .net web-applications build visual-studio-2013