Nie można załadować pliku lub zestawu „Microsoft.Build.Framework” (VS 2017)


87

Kiedy próbuję uruchomić polecenie „update-database”, pojawia się następujący wyjątek:

Określ flagę „-Verbose”, aby wyświetlić instrukcje SQL stosowane do docelowej bazy danych. System.IO.FileNotFoundException: nie można załadować pliku lub zestawu „Microsoft.Build.Framework, Version = 15.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a” lub jednej z jego zależności. System nie może odnaleźć określonego pliku. Nazwa pliku: „Microsoft.Build.Framework, Version = 15.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a”

WRN: Rejestrowanie powiązań zestawu jest wyłączone. Aby włączyć rejestrowanie błędów powiązań zestawów, ustaw wartość rejestru [HKLM \ Software \ Microsoft \ Fusion! EnableLog] (DWORD) na 1. Uwaga: Istnieje pewien spadek wydajności związany z rejestrowaniem niepowodzenia powiązania zespołu. Aby wyłączyć tę funkcję, usuń wartość rejestru [HKLM \ Software \ Microsoft \ Fusion! EnableLog].

Nie można załadować pliku lub zestawu „Microsoft.Build.Framework, Version = 15.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a” lub jednej z jego zależności. System nie może znaleźć określonego pliku.`


1
W języku niemieckim ten komunikat o błędzie brzmi: „Die Datei oder Assembly” Microsoft.Build.Framework, Version = 15.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a "oder eine Abhängigkeit davon wurde nicht gefunden".
Uwe Keim

Odpowiedzi:


93

Myślę, że miałem ten sam problem, co ty. Nie zapisałem całego komunikatu o błędzie, ale mój komunikat o błędzie to

Nie można załadować pliku lub zestawu” Microsoft.Build.Framework, Version = 15.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a ”lub jednej z jego zależności. System nie może odnaleźć określonego pliku. '

Używam programu Visual Studio 2017 i próbowałem to zrobić Update-Databasepóźniej Add-Migration.

Aby rozwiązać ten problem, zamknąłem program Visual Studio i ponownie go otworzyłem , a następnie ponownie uruchomiłem Update-Database.

To może, ale nie musi, rozwiązać twój problem, ale pomyślałem, że napiszę na wypadek, gdyby to pomogło.


6
Tak, wydaje się, że „Włącz-Wyłącz-Włącz-Ponownie” jest właściwą drogą do rozwiązania problemu w tym przypadku.
Darren Oster

16
To działa, ale nie uważam tego za poprawną odpowiedź. Chciałbym to naprawić raz na zawsze, bez konieczności ponownego uruchamiania VS.
Stanislav

1
Dzieje się tak za każdym razem po migracji teraz i wymaga pełnego ponownego uruchomienia komputera, aby działał.
OverMars

3
Wypróbowałem każde z proponowanych rozwiązań. Żaden z nich nie wydaje się trwale rozwiązać problemu. Muszę ponownie uruchamiać Visual Studio.
Augusto Barreto

4
To jest otwarty problem w Github tutaj github.com/aspnet/EntityFramework6/issues/382
Bil Simser

99

Nasz lokalny skrypt kompilacji używał starszej wersji nuget.exe( 4.7.1.5393) do przywracania pakietów NuGet. Zaczęliśmy otrzymywać ten błąd po aktualizacji do wersji Visual Studio 2019 16.5.0. Aktualizacja do najnowszej wersji nuget.exe( 5.4.0.6315) rozwiązała problem.

nuget.exemożna pobrać tutaj: https://www.nuget.org/downloads .


27
Zmierzyłem się z tym wyzwaniem, gdy zainstalowaliśmy tylko VS2019 na serwerze kompilacji. Aby rozwiązać ten problem w naszej kompilacji usługi Azure DevOps, działa żądanie wersji 5.4.0 w kroku Instalatora narzędzia NuGet.
Elder Smash

3
Zaktualizowano z 4.3.0 do 5.6 w moim TeamCity. To rozwiązało mój problem. Dzięki!
Esaith

3
To było to. Wielkie dzięki! Z 4.4.1 do 5.4.0.
DaleyKD

2
@ElderSmash Używamy również kompilacji Azure DevOps. W naszym przypadku problem został rozwiązany poprzez aktualizację kroku instalatora NuGet z NuGetToolInstaller@0do NuGetToolInstaller@1, nawet bez określania nowszej wersji. Nie jestem jednak pewien, czy to naprawia główną przyczynę problemu, czy też poprawka jest tylko efektem ubocznym wyczyszczenia lokalnej pamięci podręcznej.
MarkusM

2
@ElderSmash To był dokładnie mój problem i rozwiązanie, dzięki!
Danie

41

Główna przyczyna tego problemu pochodzi ze względnych ścieżek w devenv.exe.configpliku do Microsoft.Build.Framework.dll(patrz znaczniki xml).

Niektóre rozszerzenia programu Visual Studio zmieniają bieżący katalog i powodują, że ścieżki względne są nieprawidłowe.

Aby to naprawić, otwórz ten plik w C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\katalogu. i zamień wszystkie ..\..\MSBuild\15.0\Bin\na C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\.


Używam Visual Studio Professioal, czy powinienem zrobić to samo. Otrzymuję ten błąd wiele razy?
Shan

Nie miałem folderu MSBuild w IDE (wersja Community), skopiowałem mój MSBuild z „C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Community” i nic nie naprawiłem.
OverMars

1
Używam 2017 Pro i to rozwiązało problem. +1
Tom Wright

2
Zauważ, że jeśli zaktualizujesz VS2017 po wprowadzeniu tej poprawki, może być konieczne ponowne zaktualizowanie devenv.exe.config
Mike Peterson

2
Ta odpowiedź po prostu pomogła mi po raz drugi - po aktualizacji VS2017 musisz to zrobić ponownie, jak mówi @MikePeterson.
James Monger

35

Znalazłem obejście, które wydaje się rozwiązywać problem na dobre, przynajmniej w moim środowisku z VS 2017 Professional 15.5.2 i Entity Framework 6.1.1.

Zasadniczo zainstaluj bibliotekę DLL (wraz z kilkoma powiązanymi) w GAC (Global Assembly Cache), a problem zniknie.

Wykonaj następujące kroki:

  1. Zamknij wszystkie uruchomione wystąpienia programu Visual Studio 2017

  2. Uruchom wiersz polecenia dewelopera programu Visual Studio 2017

  3. Wpisz następujące polecenia (zamień Professional na swoją edycję, Enterprise lub Community, albo odpowiednio dostosuj ścieżkę):

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Engine.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Conversion.Core.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Tasks.Core.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll"
  1. Uruchom ponownie program Visual Studio 2017

Zasadniczo GAC (w większości przypadków) będzie miał priorytet, gdy .NET spróbuje załadować bibliotekę DLL, a wyjątek FileNotFoundException zniknie, ponieważ biblioteka DLL zostanie teraz rozwiązana za pośrednictwem GAC.

Ponownie, działa to dla mnie i jest to po prostu obejście, nie rozwiąże samego podstawowego problemu, ale przynajmniej nie muszę cały czas ponownie uruchamiać VS, gdy próbuję pracować z migracjami EF, i to jest dla mnie wystarczająco dobre.


1
Dla mnie też zadziałał. Wiersz polecenia dla deweloperów programu Visual Studio 2017 znajduje się w C: \ ProgramData \ Microsoft \ Windows \ Menu Start \ Programs \ Visual Studio 2017 \ Visual Studio Tools i musi być uruchamiany jako administrator.
David Létourneau

2
Do Twojej wiadomości - może to powodować problemy, gdy Microsoft aktualizuje produkt i wpisy GAC stają się nieważne (nowsza wersja lub zmiana ścieżki .. pro vs enterprise, itp.). Zwłaszcza problem na upgrade do najnowszej 15.8.0 Jeśli projekty nie ładują (ze względu na które korzystały z tego rozwiązania), patrz tutaj: developercommunity.visualstudio.com/content/problem/311136/...
Barry

11

To zadziałało dla mnie - wydaje się, że problem nie dotyczy wsparcia, począwszy od 2020 r.

W kroku Azure Build Pipeline> NuGet tool installerzmień Version of NuGet.exe to installna nowszą wersję, na przykład 5.4.0. Sprawdź wersje na https://dist.nuget.org/tools.json .

Problem zniknął i teraz pomyślnie się kompiluje.


Aktualizacja używanej wersji nuget była również sposobem na rozwiązanie problemu.
NP83

7

Mój brakujący plik lub wersja zestawu jest inna w przypadku pytania.

Ten błąd występuje, gdy próbuję opublikować projekt ASP.net

Microsoft.Build.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

Rozwiązałem problem, instalując Microsoft Build Tools 2015

Myślę, że mój problem spowodowany opublikowaniem projektu, który został zbudowany w VS 2015 w VS 2017. Mam nadzieję, że mogę pomóc innym, którzy mają ten sam problem.


Pomogło mi to naprawić kompilację CI w lokalnym TFS. Jeden z moich serwerów kompilacji nie miał tych narzędzi i ciągle zawodził z bardzo podobnym problemem.
Budhead2004

4

Na wszelki wypadek ponowne uruchomienie programu Visual Studio nie działa Przejdź do Menedżera zadań / Eksploratora procesów i umiejętności VBCSCompiler.exe

wprowadź opis obrazu tutaj

Zaproponuj użycie Process Explorer


1
Próbuję tego rozwiązania „Na wypadek, gdyby ponowne uruchomienie programu Visual Studio nie działało, przejdź do Menedżera zadań / Eksploratora procesów i umiejętności VBCSCompiler.exe” i działa dobrze.
Mohammad Jihad Helal


2

W moim przypadku coś (może NuGet-Update) dodało AssemblyBinding do pliku web.config:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-15.1.0.0" newVersion="15.1.0.0" />
</dependentAssembly>

Po usunięciu tej zależnej pozycji Assemby-Entry mogłem ponownie opublikować projekt.


2

To zadziałało dla mnie: błąd występuje, gdy wykonuję polecenie przywracania NuGet. Wersja Nuget 4.6.2. Mam dwa sposoby rozwiązania tego problemu.

Użyj Nuget 4.8.2 i nowszych. gacutil / i "C: \ Program Files (x86) \ Microsoft Visual Studio \ 2019 \ Professional \ MSBuild \ Current \ Bin \ Microsoft.Build.Framework.dll


1

Mieliśmy ten problem i oto, co musieliśmy zrobić w naszym przypadku:

Problem polegał na tym, że mieliśmy (IDbCommandInterceptor)skonfigurowany przechwytywacz poleceń bazy danych, który wywoływał HttpRuntime.Cache["somekey"] iz jakiegoś powodu polecenia migracji nie działały z tego powodu. Po usunięciu tej zależności wszystkie polecenia działały idealnie. Może HttpRuntimenie mogłeś znaleźć biblioteki DLL Build Framework?

Sprawdź więc cały stos wywołań, gdy polecenia migracji nie sprawdzają, czy masz podobny problem.


Bardzo interesujące, mój ślad stosu zawierał wywołanie metody używającej HttpContext.Current. Usunięcie tego spowodowało usunięcie problemu.
Timores,

0

Napotkałem ten sam problem, gdy zaktualizowałem komponenty XCode / Mono w systemie macOS.

Rozwiązaniem jest zaktualizowanie programu Visual Studio dla komputerów Mac do najnowszej wersji.

Myślę, że ten problem powoduje użycie nowych narzędzi MSBuild z pakietu .NET Core 3.0, który został zainstalowany z nową wersją XCode / Mono.


0

Podziękowania dla tych, którzy już opublikowali. Moja sytuacja została rozwiązana przez kombinację powyższych. Miałem kilka wersji Visual Studio: 2015, 2017, 2019. W pewnym momencie wersja MSBUILD zmieniła się z 15.1 na 15.9 i rozwiązałem ten problem, aktualizując C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.exe.configplik tak, aby wskazywał na bibliotekę 15.9. Oto przykład jednego z wpisów:

<dependentAssembly>
      <assemblyIdentity name="Microsoft.Build.Utilities.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
      <bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.9.0.0"/>
      <codeBase version="15.9.0.0" href="..\..\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll" />
</dependentAssembly>

2
wydaje się, że twój przykład zniknął.
Jammer

0

Korzystanie z programu Visual Studio 2019 Community Edition. Próbowałem innych rozwiązań bez powodzenia, ale po wyczyszczeniu pamięci podręcznej NuGet problem wydawał się być rozwiązany. wprowadź opis obrazu tutaj


0

Po wypróbowaniu wszystkich powyższych metod i nie tylko - uruchomiona WCFaplikacja nadal mi się nie udała. Błąd: Could not load file or assembly 'Microsoft.Build.Framework, Version=15.1.0.0...

uwaga: próbowano Restartowanie VS, PC, zabijanie procesów, czyszczenie pamięci podręcznych VS, nuget cache, obj, bin, .vs, foldery pakietów

U mnie zadziałało usunięcie *.csproj.userpliku projektów . Najwyraźniej miał w sobie jakąś przestarzałą konfigurację. Straciłem 4 godziny, próbując to rozgryźć.


0

Zrestartowałem, po czym stwierdziłem, że lokalna usługa sieciowa, z której korzystałem, została zablokowana przez inny proces, który zajął ten port. Sprawdziłem działający proces i zabiłem go za pomocą TCPView i wszystko wydawało się znowu działać.

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.