Błąd kompilacji zewnętrznego VS2013 „błąd MSB4019: Nie znaleziono importowanego projektu <ścieżka>

Buduję projekt za pomocą wiersza polecenia, a nie w programie Visual Studio 2013. Uwaga: Zaktualizowałem swój projekt z Visual Studio 2012 do 2013. Projekt działa dobrze w środowisku IDE. Ponadto najpierw całkowicie odinstalowałem VS2012, uruchomiłem ponownie i zainstalowałem VS2013. Jedyną wersją programu Visual Studio, którą posiadam, jest wersja Ultimate 2013.

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.

Oto dwie omawiane linie:

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

Pierwszą drugą linią była wersja 10.0, ale ręcznie zmieniłem ją na wersję 12.0.

$ (VSToolsPath) wydłuża się z tego, co widzę, do folderu v11.0 (VS2012), którego oczywiście już nie ma. Ścieżka powinna być do wersji 12.0.

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

Próbowałem określić VSToolsPath w mojej tabeli zmiennych środowiskowych systemu, ale zewnętrzne narzędzie kompilacji nadal używa wersji 11.0. Próbowałem przeszukać rejestr, ale nic nie wyszło.

Niestety nie widzę łatwego sposobu uzyskania dokładnej linii poleceń. Używam narzędzia do budowania.

Myśli?

Miałem ten sam problem i znajdowałem łatwiejsze rozwiązanie

Wynika to z dodania Vs2012 do pliku csproj:

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

Możesz bezpiecznie usunąć tę część, a Twoje rozwiązanie zostanie zbudowane.

Jak zauważył Sielu, musisz upewnić się, że plik .proj zaczyna się od, w <Project ToolsVersion="12"przeciwnym razie przy następnym otwarciu projektu w Visual Studio 2010 doda ponownie usunięty węzeł.

W przeciwnym razie, jeśli chcesz użyć webdeploy lub serwera kompilacji, powyższe rozwiązanie nie będzie działać, ale możesz określić VisualStudioVersionwłaściwość w skrypcie kompilacji:

msbuild myproject.csproj /p:VisualStudioVersion=12.0

lub edytuj definicję kompilacji:

Ja też to miałem i możesz to naprawić, ustawiając wersję narzędzi w definicji kompilacji.

To jest bardzo łatwe do zrobienia. Otwórz definicję kompilacji i przejdź do strony „ Proces ”. Następnie w grupie „ 3. Zaawansowane ” masz właściwość o nazwie „ Argumenty MSBuild ”. Umieść tam parametr o następującej składni

/p:VisualStudioVersion=12.0 

Jeśli masz więcej parametrów, oddziel je spacją, a nie przecinkiem.

Jest to ściśle powiązane, ale może, ale nie musi, rozwiązać konkretny problem PO. W moim przypadku próbowałem zautomatyzować wdrożenie witryny Azure przy użyciu VS2013. Budowanie i wdrażanie za pomocą VS działa jednak przy użyciu MSBuild wykazywał podobny błąd wokół „celów”. Okazuje się, że MSBuild różni się w VS2013 i jest teraz częścią VS, a nie .Net Framework (patrz http://timrayburn.net/blog/visual-studio-2013-and-msbuild/ ). Zasadniczo użyj poprawnej wersji MSBuild:

OLD, VS2012

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

NOWOŚĆ, VS2013

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

Nowsze, VS2015

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

Nadal nowszy, VS2017 (nie w pełni testowany, ale wykryty - trochę się poruszyli)

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

Właśnie otrzymałem odpowiedź od Kinook, który dał mi link :

Zasadniczo muszę zadzwonić do następujących przed budowaniem. Wydaje mi się, że Visual Studio 2013 nie rejestruje najpierw automatycznie środowiska, ale 2012 r. Zrobił to lub zrobiłem i zapomniałem.

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

Mam nadzieję, że ten post pomoże komuś innemu.

rozwiązanie giammin jest częściowo niepoprawne. Ty NIE POWINNY usunąć tę całą PropertyGroup od rozwiązania. Jeśli to zrobisz, funkcja „DeployTarget = Package” MSBuild przestanie działać. Ta funkcja zależy od ustawienia „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)' != ''" />

Miałem ten problem z naszymi celami FSharp (FSharpTargetsPath był pusty).

Wiele ścieżek jest budowanych w odniesieniu do wersji VS.

Z różnych powodów nasza kompilacja działa z uprawnieniami systemowymi, a zmienna środowiskowa „VisualStudioVersion” została ustawiona (przez instalatora VS 2013) tylko na poziomie „użytkownika” - co jest dość uczciwe.

Upewnij się, że VisualStudioVersionzmienna środowiskowa „ ” jest ustawiona na „ 12.0” na poziomie (system lub użytkownik), na którym pracujesz.

Uruchomienie tego w wierszu polecenia również rozwiąże problem. SETX VisualStudioVersion „12.0”

Jeśli przeprowadzisz migrację programu Visual Studio 2012 do 2013, otwórz plik projektu * .csprorj za pomocą programu edior.
i zaznacz element ToolsVersion znacznika „Project”.

To wartość 4,0.
Dajesz 12,0

• Z

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

• Do

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

Lub Jeśli budujesz z msbuild, po prostu określ właściwość VisualStudioVersion

msbuild /p:VisualStudioVersion=12.0

Korzystałem z zewnętrznego narzędzia do kompilacji. Pomyśl o czymś takim jak mrówki, jeśli dobrze rozumiem produkt, to tylko wersja komercyjna. Aby uzyskać odpowiedź, musiałem skontaktować się z producentem.

Jak się okazuje, w projekcie znajduje się globalne makro DEVSTUDIO_NET_DIR. Musiałem zmienić ścieżkę do .Net tam. Wymieniają różne wersje studia wizualnego jako „Akcje”, które za mną, ale wszystkie drogi prowadzą z powrotem do tej jednej globalnej zmiennej za kulisami. Wymieniłbym to jako wadę produktu, gdybym miał na to sposób, chyba że coś mi brakuje. Poprawienie ścieżki tam rozwiązało problem kompilacji.

Mam zainstalowany program Visual Studio 2013. To działało dla mnie:

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

Więc zmieniłem warunek z ==na !=i wartość z 10.0na 12.0.

Miałem podobny problem. Wszystkie proponowane rozwiązania dotyczą tylko tego problemu, ale nie rozwiązują źródła błędów. Rozwiązania @giammin nie należy stosować, jeśli używasz serwera kompilacji tfs, ponieważ jest to tylko awaria funkcji publikowania. @ cat5dev solution - rozwiązuje problem, ale nie rozwiązuje jego źródła.

Jestem prawie pewien, że używasz szablonu procesu kompilacji dla VS2012, tak jak ReleaseDefaultTemplate.11.1.xaml or DefaultTemplate.11.1.xaml te szablony kompilacji zostały przygotowane dla VS2012 i $ (VisualStudioVersion) ustawiono na 11,0

Państwo powinno użyć szablonu procesu kompilacji dla VS2013 ReleaseTfvcTemplate.12.xaml or TfvcTemplate.12.xaml , który ma $ (VisualStudioVersion) zestaw do 12,0

Działa to bez żadnych zmian w pliku projektu.

Miałem również ten sam błąd. Zrobiłem to, aby to naprawić

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

zmień na

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

i gotowe.

W moim przypadku po prostu komentuję poniżej linii, otwierając plik .csproj i wykonałem lewę

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

Mój problem może być inny, ale zostałem tutaj przeciągnięty, ale może to komuś pomóc.

Wybrałem pojedynczy projekt internetowy z mojego rozwiązania i próbuję go otworzyć jako samodzielny projekt, który powodował problemy, po czym do cholery jestem w stanie rozwiązać problem.

Użyj poprawnej wersji MSBuild. Ustaw zmienną środowiskową na:

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

Będzie to również działać w przypadku projektów VS 2019

Wcześniej ustawiliśmy to na C:\Windows\Microsoft.NET\Framework\v4.0.30319

W moim przypadku środowiskiem programistycznym jest VS2013 i korzystam z TFS 2010. Kompilacja była skierowana do .NET 4.5.1. Konfigurowałem automatyczną kompilację dla CI. za każdym razem, gdy próbowałem obejść powyższe obejścia - jak całkowite usunięcie grupy właściwości lub zastąpienie niektórych wierszy itp. moja kompilacja zdarzała się w TFS, ale moja publikacja na lazur kończyła się niepowodzeniem przy pomocy „MSDeploy” lub czasami innego błędu. Nie udało mi się osiągnąć obu jednocześnie.

W końcu musiałem przekazać argument MSBuild, aby rozwiązać problem.

Idź do Edycja definicji kompilacji> Proces> 3. Zaawansowane> Argumenty MSBuild (ustawione na) /p:VisualStudioVersion=12.0

To zadziałało dla mnie.

Należy skopiować folder WebApplications z C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v12.0 \ do C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \

znajdziesz

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

w pliku csproj, dla którego występuje ten błąd. Po prostu usuń to z csproj, a następnie skompiluj.

Aby rozwiązać problem, należy zrobić tylko jedną rzecz: zaktualizować TeamCity do wersji 8.1.x lub nowszej, ponieważ obsługa Visual Studio 2012/2013 i MSBuild Tools 2013 została wprowadzona tylko w TeamCity 8.1. Po uaktualnieniu TeamCity zmodyfikuj ustawienie MSBuild Tools Version w kroku kompilacji, a problem zniknie. Aby uzyskać więcej informacji, przeczytaj tutaj: http://blog.turlov.com/2014/07/upgrade-teamcity-to-enable-support-for.html

Ja - nic nie pomagało w zmianie wartości v11.0 zmiennej VisualStudioVersion na v10.0. Zmiana zmiennej w pliku .csproj nie. Ustawienie tego za pomocą polecenia polecenia nie. Itp...

Skończyło się kopiowanie mojego lokalnego folderu tej konkretnej wersji (v11.0) na mój serwer kompilacji.

Wypróbowałem wszystkie powyższe rozwiązania i nadal nie mam szczęścia. Słyszałem, jak ludzie instalowali program Visual Studio na swoich serwerach kompilacji, aby to naprawić, ale miałem tylko 5 GB wolnego miejsca, więc właśnie skopiowałem C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio na mój serwer kompilacji i nazwałem to dniem . Następnie zaczął pracę, korzystając z Team City 9.x i Visual Studio 2013.

Na podstawie serwera kompilacji TFS 2015

Jeśli przeciwdziałasz temu błędowi ... 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.

Otwórz .csprojplik projektu o nazwie podanej w komunikacie o błędzie i skomentuj poniższą sekcję

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

Wystąpił ten błąd podczas instalowania niektórych składników VS. Niestety żadna z tych odpowiedzi mi nie pomogła. Używam TFS do programowania poleceń i nie mam uprawnień do edytowania definicji kompilacji. Rozwiązałem ten problem, usuwając zmienne środowiskowe, które wywoływały VS110COMNTOOLSi VS120COMNTOOLS. Myślę, że został zainstalowany z moimi komponentami VS.

Odkryłem, że brakuje mi folderu WebApplications na moim lokalnym komputerze, nie zainstalowałem się z Visual Studio 2017 tak jak wtedy, gdy korzystałem z 2012 roku.

W moim przypadku użyłem niewłaściwej wersji MSBuild.exe.

Wersja, której należy użyć, zależy od wersji programu Visual Studio użytej do utworzenia projektu. W moim przypadku potrzebowałem 14.0 (po użyciu Visual Studio 2015).

Znaleziono to:

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

Możesz zajrzeć pod:

C:\Program Files (x86)\MSBuild

Aby znaleźć inne wersje.