Przeszukałem ten problem, ale żadne z rozwiązań nie zadziałało. Mam zainstalowany program Visual Studio Professional 2015 i korzystam z TFS. Moja wersja NuGet to 3.1.6. Ten problem występuje tylko w moim projekcie C # Web API / MVC.

Pojawia się następujący błąd:

Ten projekt odwołuje się do pakietów NuGet, których brakuje na tym komputerze. Aby je pobrać, użyj Przywracania pakietu NuGet. Aby uzyskać więcej informacji, zobacz http://go.microsoft.com/fwlink/?LinkID=322105 . Brakującym plikiem jest .. \ packages \ Microsoft.Net.Compilers.1.0.0 \ build \ Microsoft.Net.Compilers.props

1. Nie mam folderu .nuget w moich rozwiązaniach.
2. Mam rozwiązanie w folderze pakietów i kiedy go usuwam, wygląda na to, że NuGet odbudowuje zależności, ale w projekcie nadal występuje powyższy błąd.
3. Próbowałem usunąć projekt z TFS i nie udało się go naprawić.
4. Oprócz powyższego błędu wszystkie odniesienia w projekcie mają żółte znaki ostrzegawcze i informują, że ich brakuje.
5. Kiedy sprawdziłem Menedżera pakietów NuGet dla projektu, wszystko, co „brakuje”, ma zielony znaczek obok, w tym Microsoft.Net.Compilers.
6. Próbowałem dodać nowy projekt Web API / MVC i napotkałem podobny problem, w którym większość referencji takich jak Owin „brakowało” z żółtym znakiem ostrzegawczym.

Miałem dzisiaj ten sam błąd (brak dokładnie tego samego pakietu). Stworzyłem również projekt interfejsu API sieci MVC +.

Stało się tak, ponieważ przeniosłem pliki aplikacji (w tym .csproj) w inne miejsce. Ręcznie zaktualizowałem plik .sln, ale wszystkie zależności pakietów są teraz (Visual Studio 2015) przechowywane w pliku .csproj.

Edycja pliku .csproj i poprawianie ścieżki względnej do folderu rozwiązania (zawierającego folder paczek) rozwiązało problem.

Rozwiązałem problem, usuwając ten kod z .csprojpliku:

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
  <PropertyGroup>
    <ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
  </PropertyGroup>
  <Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>

UWAGA - to aktualizuje pakiety dla całego rozwiązania, nie tylko projektu.

Jeśli masz jeszcze jeden brakujący pakiet nuget, który podaje błąd podczas budowania rozwiązania, użyj następującego polecenia za pomocą konsoli poleceń Nuget z Narzędzia> Menedżer pakietów Nuget> Konsola Menedżera pakietów. Ponownie zainstaluje wszystkie twoje aktualne pakiety.

Update-Package –reinstall

Aktualizacja:

Możesz przekazać określoną nazwę projektu jako parametr.

Update-Package –reinstall -ProjectName SampleApp

Miałem dokładnie taką frustrującą wiadomość. To, co w końcu zadziałało, to usunięcie wszystkich plików i folderów wewnątrz / pakietów i pozwolenie VS ponownie pobrać wszystko z kolejnej kompilacji.

Tiberiu ma rację. Musiałem edytować plik .csproj, ponieważ pliki zostały przeniesione i spowodowało ten problem

 <Import Project="..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />

Zmieniłem na górze pliku i na dole

<Error Condition="!Exists('..\..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props'))" />
<Error Condition="!Exists('..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />

w ten sposób rozwiązałem mój błąd: Aby otworzyć plik .csproj do aktualizacji w Visual Studio 2015+ Solution Explorer:

Kliknij prawym przyciskiem myszy nazwę projektu -> Rozładuj projekt

Kliknij prawym przyciskiem myszy nazwę projektu -> Edytuj .csproj

Usuń następujące wiersze:

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
    <PropertyGroup>
      <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
    </PropertyGroup>
    <Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props'))" />
    <Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
    <Error Condition="!Exists('packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', 'packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props'))" />
    <Error Condition="!Exists('packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', 'packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
  </Target>

Kliknij prawym przyciskiem myszy nazwę projektu -> Załaduj ponownie projekt

Wreszcie zbuduj swoje rozwiązanie.

Rozwiązałem ten problem, usuwając następujący kod z pliku .csproj

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
  <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\..\..\Assemblies\NuGet\SpecFlow.Plus.Excel.1.4.2\build\SpecFlow.Plus.Excel.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\..\..\Assemblies\NuGet\SpecFlow.Plus.Excel.1.4.2\build\SpecFlow.Plus.Excel.targets'))" />

Kombinacja 2 odpowiedzi zadziałała dla mnie. Najpierw zmodyfikowałem plik .csproj, aby usunąć odwołanie do wersji 1.0.0

< Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild" >

  ----Error---

< /Target>

a potem zrobił

Update-Package -Reinstall

od i zadziałało.

Dla mnie problem polegał na tym, że kiedy skopiowałem rozwiązanie do nowego folderu i otworzyłem go, brakowało folderu Nuget, jak pokazano poniżej. Skopiowałem ten folder i wszystko działało. Uwaga: ten sam folder był w naszej kontroli źródła, ale nie w tym projekcie rozwiązań, był w jednym katalogu.

Wystarczy włączyć Przywracanie pakietu NuGet. Kliknij prawym przyciskiem myszy swoje rozwiązanie> wybierz „Włącz przywracanie pakietu NuGet”.

Spowoduje to utworzenie folderu .nuget z plikiem NuGet.Config i naprawienie mojego problemu.

Używam VS2012 i napotyka ten sam błąd. Usunąłem następujący znacznik docelowy z pliku .csproj i zaczął się kompilować bez żadnego błędu.

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
  -- Error messages within Target Tag
</Target>

Aby rozwinąć kilka odpowiedzi tutaj, tak, możesz usunąć następujący blok z pliku .csproj:

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">

i to rozwiązuje problem, jednak w moim przypadku zauważyłem, że miałem dodatkowe odniesienia do .NET.Compilers i .CodeDom.Providers z różnymi wersjami:

<Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.1.0.0
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\

<Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.2.0.1
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.3\

Gdy moja paczka.config odnosiła się tylko do następujących elementów:

<package id="Microsoft.Net.Compilers" version="2.0.1"
<package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.3"

Usunięcie elementów 1.0.0 z pliku .csproj rozwiązało problem.

Dla każdego, kto natknie się tutaj na problem, który miałem (niektóre, ale nie wszystkie pakiety są przywracane na serwerze kompilacji), ostatnim elementem układanki było dla mnie dodanie NuGet.config w katalogu głównym mojego rozwiązania, rodzeństwa do .SLN plik, jak wyjaśnił David Ebbo tutaj: http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html .

Z postu na blogu Ebbo zawartość pliku jest po prostu dla mnie

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
</configuration>

AKTUALIZACJA:

Adres URL interfejsu API NuGet został zmieniony dla wersji 3 (aktualny na wrzesień 2016). Od https://www.nuget.org/

<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />

Komunikat o błędzie jest całkowicie poprawny. Próbowałem wszystkich sztuczek i żadna nie działała. Projekt (prosty test aplikacji MVC Web) został przeniesiony ze społeczności Windows 8.1 VS 2015 Community do mojego nowego pola testowego w systemie Windows 10. Zastosowano wszystkie najnowsze aktualizacje VS 2015. Nie mogłem nawet zainstalować żadnej nowszej wersji pakietu kompilatorów.

Loop:
<LOOP>This seems to be a Ground Hog Day phenomena.</LOOP>
GoTo Loop

W końcu właśnie skopiowałem Microsoft.Net.Compilers.1.0.0 ze starego projektu do nowego i działało. Mógłbym wtedy zacząć aktualizować inne pakiety do nowszej wersji. Wygląda mi na błąd w procesie aktualizacji projektu nuget.

UWAGA: Oryginalny projekt został utworzony w VS 2015 i nie ma żadnych starszych metodologii.

Rozwiązanie, które działa w moim przypadku - Visual Studio 2015 Enterprice, projekt .NET 4.6.1

1. Uaktualnij do aktualizacji 3
2. Zainstaluj narzędzia dla programistów internetowych

Dla mnie pakiety znajdowały się pod właściwą ścieżką, ale foldery kompilacji w folderze pakietu nie. Po prostu usunąłem wszystkie pakiety, których brakowało, i przebudowałem rozwiązanie i pomyślnie utworzyłem foldery kompilacji i pliki .props. Więc komunikaty o błędach były prawidłowe, informując mnie, że coś jest nieudane.

Miałem ten problem jako nieudaną kompilację na platformie Azure podczas wdrażania z Git.

Okazało się, że mój .gitignore wykluczał buildfolder z ..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props.

Gdy buildfolder został (wymuszony) przekazany do Git, problem został rozwiązany.

Rozwiązałem ten sam problem, wykonując następujące czynności

1. Usunięto pakiet <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="2.0.1" targetFramework="net46" />z pliku package.config.

2. Edytuj plik projektu .csproj i usuń poniższe ustawienia. <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">     <PropertyGroup>       <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>     </PropertyGroup>     <Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />   </Target>

   3. Przejdź do konsoli menedżera pakietów i uruchom polecenie Update-Package –reinstall

Punkty 2 i 3 zostały podane przez innych użytkowników i doceniam tych użytkowników. Punkt # 1, usuwającMicrosoft.CodeDom.Providers.DotNetCompilerPlatform pliku z pliku package.config jest ważniejsze. Ponadto po uruchomieniu polecenia wymienionego w punkcie # 3 problem został rozwiązany. Wszystkie niechciane pakiety zostały usunięte i zaktualizowano wymagane odniesienie do pakietu.

Mam nadzieję, że to komuś pomoże.

Nie mogłem znaleźć żadnych rozwiązań tego problemu, więc dodałem kopię nuget.exe i skrypt PowerShell do katalogu głównego rozwiązania o nazwie prebuild.ps1 z następującą zawartością.

$nugetexe = 'nuget.exe'
$args = 'restore SOLUTION_NAME_HERE.sln'
Start-Process $nugetexe -ArgumentList $args

Nazwałem ten skrypt PowerShell w mojej kompilacji na ścieżce skryptu przed kompilacją

Mój działał, gdy skopiowałem folder pakietów wraz z plikiem rozwiązania i folderem projektu. Po prostu nie skopiowałem folderu paczek z poprzedniego miejsca.

Sugerowanego komunikatu o błędzie można również użyć jako podpowiedzi. Oto jak znaleźć Zarządzaj pakietami dla rozwiązania i kliknij przycisk rozwiązywania brakującego pakietu nuget.

Otóż ​​to

Skomentuj opcję kompilatora w WebConfig:

<!--<system.codedom>
<compilers>
  <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701" />
  <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" />
</compilers>
</system.codedom>-->

Zaktualizuj najnowszą wersję pakietów w pliku konfiguracji pakietu

  <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.4" targetFramework="net452" />

Odbuduj, jeśli wszystko jest w porządku, nie musisz kontynuować, w przeciwnym razie kliknij projekt prawym przyciskiem myszy, kliknij polecenie „zwolnij projekt” Kliknij ponownie projekt prawym przyciskiem myszy i edytuj plik .csproj

Zweryfikuj ścieżkę Codedom, nie miała ona net45 w poprzednich ścieżkach, dodaj ją ręcznie, zapisz, załaduj, odbuduj. To powinno działać.

<Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.4\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.4\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />

Jak wielu sugeruje usunięcie <Target>tagu, może to umożliwić jego kompilację. Uważaj jednak na to, że ma to efekt uboczny, gdy robisz to dla projektów testowych.

MSTest.TestAdapterPodczas kompilacji wystąpił błąd związany z pakietem nuget. Rozwiązano ten problem, usuwając <Target>tag. Mimo że kompilacja zakończyła się sukcesem, metody testowe stały się niemożliwe do wykrycia. Eksplorator testów nie wypisze metod testowania w tym projekcie, a Uruchom test lub Test debugowania również nie zadziała.

Zetknąłem się z tym podczas używania Visual Studio 2017i .Net framework 4.7, może się to zdarzyć w innych wersjach

Problemem było dla mnie to, że NuGet nie mógł automatycznie pobrać / zaktualizować pakietów, ponieważ pełna ścieżka do pliku byłaby zbyt duża. Naprawiono poprzez przeniesienie mojego rozwiązania do folderu w moich Dokumentach zamiast głęboko zagnieżdżonego folderu .

Następnie możesz kliknąć rozwiązanie prawym przyciskiem myszy i wybrać „Przywróć pakiety NuGet” (co prawdopodobnie nie jest konieczne, jeśli tylko go zbudujesz i pozwól mu to zrobić za Ciebie), a następnie wybierz „Zarządzaj pakietami NuGet dla rozwiązania”, aby uzyskać wszystkie pakiety zaktualizowany do najnowszej wersji.

Dotyczyło to rozwiązania przykładowej aplikacji ASP MVC pobranej ze strony internetowej Microsoft.

W przypadku inżynierów DevOps / build możesz prawdopodobnie naprawić to działanie w nuget restorestosunku do dotkniętej SLN lub projektu, jeśli brakuje SLN. Muszę to zrobić dla naszych kompilacji CI / CD dla wszystkich naszych projektów UWP.

1. Upewnij się, że nuget jest zainstalowany na kompilacji slave w Visual Studio lub autonomicznie. Jeśli to jest to drugie, upewnij się, że jest w ŚCIEŻCE i pomiń krok 2.
2. Otwórz konsolę VS Dev CMD lub załaduj ją za pomocą już otwartej, co możesz zrobić, wykonując poniższe instrukcje:
   VS2015 call "%VS140COMNTOOLS%VsDevCmd.bat"
   lub
   VS2017call "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat"
3. call nuget restore MyStuff.SLNlub call nuget restore MyStuff.csprojjeśli nie ma SLN.

Nie jestem pewien, czy to pomoże komukolwiek, ale pojawił się ten problem, gdy usunąłem kod źródłowy z mojego komputera lokalnego bez zapisywania pliku rozwiązania w TFS. (Podczas wstępnego programowania kliknąłem prawym przyciskiem myszy i sprawdzałem projekt w Eksploratorze rozwiązań, ale zapomniałem kiedykolwiek sprawdzać samego rozwiązania.) Kiedy musiałem pracować nad tym ponownie, w TFS miałem tylko plik .csproj, brak pliku .sln. Tak więc w VS zrobiłem Plik -> Kontrola źródła -> Zaawansowane - Otwórz z serwera i otworzyłem plik .csproj. Stamtąd zrobiłem Zapisz wszystko i zapytało mnie, gdzie chcę zapisać plik .sln. Zapisałem ten plik .sln w katalogu projektu z innymi folderami (App_Data, App_Start itp.), A nie katalogiem najwyższego poziomu. W końcu doszedłem do wniosku, że muszę zapisać plik .sln w katalogu z folderu projektu, aby „ s na tym samym poziomie co folder projektu. Wszystkie moje ścieżki zostały rozwiązane i mogłem je ponownie zbudować.

Dla mnie mój plik gitignore ignorował mój folder paczek. Następująca linia gitignore była przyczyną problemu -

**/packages/*

Usunięto i przywrócono folder moich pakietów. Mam nadzieję, że to pomaga komuś innemu.

Naprawiłem ten błąd, w rzeczywistości miałem inną wersję MSTest.TestAdapter (1.3.2) w folderze pakietów, a odniesienia do plików .csproj wskazywały na MSTest.TestAdapter (1.1.0). Zamieniłem wszystkie MSTest.TestAdapter (1.1.0) na MSTest.TestAdapter (1.3.2), co rozwiązało mój problem.

Zdaję sobie sprawę, że to pytanie jest stare, ale dzisiaj spotkałem się z tą samą sytuacją i chciałem wrzucić moje 2 centy za każdego, kto niedawno odkrył ten problem. Projekt ASP MVC, który ręcznie przeniosłem do podfolderu w moim rozwiązaniu, a następnie usunąłem i ponownie przeczytałem w rozwiązaniu, używając programu Visual Studio 2017, dawał wspomniany błąd. Przeniesienie folderów „lib” i „paczek” do katalogu głównego tego samego podfolderu, co projekt MVC, rozwiązało mój problem.

Miałem ten sam problem, okazuje się, że jeden z projektów, do których się odwoływałem, znajdował się poza katalogiem rozwiązania (dlatego też nie współużytkował tego samego folderu „/ packages”). Rozwiązaniem, które działało dla mnie, było otwarcie rozwiązania projektu referencyjnego i zbudowanie go tam. Po zbudowaniu projektu błędy zniknęły.