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


201

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?



W moim przypadku musiałem określić poprawną VisualStudioVersion w zdarzeniu kompilacji, które budowało się z celem WebPublish.
user145400,

Odpowiedzi:


250

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:

edytuj definicję kompilacji, aby określić właściwość <code> VisualStudioVersion </code>


1
Wystąpił błąd przy użyciu msbuild z wiersza polecenia. Usunięcie tej części z pliku projektu spowodowało problem.
Peter Hedberg

7
Użyłem tej odpowiedzi i zadziałało tylko wtedy, gdy upewniłem się, że mój plik * proj zaczyna się od <Project ToolsVersion = "12" Zanim miałem <Project ToolsVersion = "4" i za każdym razem, gdy otwierałem projekt w VS, dodawałem ponownie dwa węzły (tj. ponownie migrował projekt do najnowszej wersji).
Sielu

3
@giammin, już znalazłem rozwiązanie. NIE usuwaj sekcji z pliku projektu. Ustaw odpowiednią 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”. Oczywiście bez cytatów. Jeśli masz więcej parametrów, oddziel je spacją, a nie przecinkiem. Konfiguracja, którą zasugerowałeś do usunięcia, jest używana przez inne części visual studio w twoim procesie kompilacji ...
Ralph Jansen

9
Usunięcie tej linii wydaje się przerywać Wdrażanie sieci
Colin Pear

4
Ten sam problem został rozwiązany za pomocą właściwości /p:VisualStudioVersion=12.0 zgodnie z zaleceniami powyżej. Dzięki
Randeep,

70

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.


1
Właśnie zakończyliśmy aktualizację z TFS 2005 do TFS 2013 i była to nasza ostatnia przeszkoda. To zdecydowanie działało dla nas i uratowało mnie przed wyciągnięciem włosów. Dzięki wielkie! +1.
Simon Whitehead,

2
W tym artykule Sayed Ibrahim Hashimi opisano problem w programie Visual Studio 2010/2012. Kompilacja wiersza poleceń używa formatu pliku sln w wersji -1 jako VisualStudioVersion. Możesz zastąpić tę wartość z wiersza poleceń, jak opisuje Ralph, lub jako właściwość zadania MSBuild ze skryptu kompilacji. Miałem ten sam problem z Visual Studio 2013, a zastąpienie VisualStudioVersion rozwiązało problem.
mcdon,

1
To również działało dla nas. Zastanawialiśmy się również nad modyfikacją samego szablonu kompilacji, opisanego tutaj , co może być lepszą opcją, jeśli masz dziesiątki definicji kompilacji.
JamesQMurphy,

to działało dla mnie. Usunąłem w plikach csproj wszelkie odniesienia do visualstudioversion, a następnie dodałem ten argument msbuild
Jhayes2118

51

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

Naprawiłem to dla mnie. Również podobna odpowiedź na podobne pytanie tutaj: stackoverflow.com/a/19826448/61569
Anthony F

22

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.


Dziękuję bardzo, to rozwiązało mój problem podczas budowania nodeJS, node-gypktórego Cpp default.propsnie znaleziono! +1
Pogrindis,

21

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)' != ''" />

10

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.


5
Jest to prawdopodobnie częsty scenariusz podczas uruchamiania serwera kompilacji (takiego jak CruiseControl lub TeamCity), w którym usługa działa na określonym koncie usługi, które może nawet nie mieć uprawnień do interaktywnego pulpitu. Ta wskazówka rozwiązała dla mnie problem (VS 2013 zainstalowany na czystej instalacji Server 2008 R2 z CruiseControl.NET)
David Keaveny

Gdzie mogę zobaczyć moją „VisualStudioVersion”?
WEFX

@ WEFX wyświetl zmienne środowiskowe, wybierając Systemz Panelu sterowania, a następnie wybierz Advanced system settings, a na koniec kliknijEnvironment Variables
Scott

6

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


To działało dla mnie i lepiej było zmodyfikować plik projektu.
Sean

4

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


1
ToolsVersion nie może być jedyną zmienną, która naprawia ten komunikat o błędzie, ponieważ widziałem projekt z ToolsVersion, który nie mógł poprawnie zbudować.
Patrick Desjardins

2

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.


2

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.


2

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.


2

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.


2

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.


2

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


Użyłem „C: \ Program Files (x86) \ Microsoft Visual Studio \ 2019 \ Enterprise \ MSBuild \ Current \ Bin \ MSBuild.exe” zamiast „C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ MSBuild. exe ”i jego prace
ELKALAKHI Mohammed

Tak, używam projektu SSDT (.sqlproj) z VisualStudioVersion = 14.0 w pliku projektu. Zainstalowałem rdzeń 3.1, który ustawił moje zmienne środowiskowe dla celów, aby Bóg tylko wiedział, gdzie. Korzystanie z msbuild w folderze, który zasugerowałeś, działało jak urok!
Matthew Beck

1

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.


1

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 \


Lub skopiuj tylko plik Microsoft.WebApplication.targets z lokalizacji, w której jest zainstalowany program Visual Studio 2013.
ThatBlairGuy

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.


0

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


0

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.


0

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.


0

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


0

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.


0

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.


0

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.