Nie można znaleźć pliku metadanych VS 2017 „.dll”

Wiem, że jest inne pytanie z dokładnie tym samym problemem, ale przeszedłem przez wszystkie odpowiedzi i żadna mi nie pomogła. :( ( To było pytanie. )

Właśnie utworzyłem nowy projekt ASP.NET MVC i dołączyłem do kilku plików dll w rozwiązaniu. Teraz, gdy próbuję zbudować projekt, pojawia się komunikat o błędzie pokazany poniżej w 3 z 5 bibliotek.

Error   CS0006  Metadata file 'C:\Users\...\source\Database\bin\Debug\DataAccessLayer.dll' could not be found   Logic   C:\Users\...\source\Logic\CSC   1   Active

Error   CS0006  Metadata file 'C:\Users\...\source\Logic\bin\Debug\Logic.dll' could not be found    PTS2-MVC    C:\Users\...\source\PTS2-MVC\CSC    1   Active

Error   CS0006  Metadata file 'C:\Users\...\source\PTS2-MVC\bin\PTS2-MVC.dll' could not be found    PTS2-MVC.Tests  C:\Users\...\source\PTS2-MVC.Tests\CSC  1   Active

Kiedy przechodzę do folderu bin \ debug tego pliku .dll, widzę, że jest pusty, a drugi plik .dll, w którym nie pojawia się komunikat o błędzie, nie jest pusty. Ale nie mam pojęcia, jak to naprawić lub co zrobiłem, aby to się stało.

Najczęstszą odpowiedzią jest, aby przejść do właściwości tego rozwiązania i przejdź do konfiguracji i odznacz -> zastosowanie -> Kontrola i stosować ponownie, ale to nie działa

Problem polegał na tym, że w moim projekcie pojawiły się inne normalne komunikaty o błędach i najwyraźniej po ich naprawieniu i po wyczyszczeniu i zbudowaniu projektu PONOWNIE, wszystkie pliki .dll zakończyły się sukcesem.

Upewnij się, że nie masz żadnych innych komunikatów o błędach w swoim projekcie, a jeśli tak, najpierw je napraw!

Kroki w celu rozwiązania tego błędu: Nie można znaleźć pliku .dll metadanych.

1. Wyczyść wszystkie projekty.

2. Zwolnij wszystkie projekty.

3. Wczytaj ponownie wszystkie projekty.

4. Przebuduj rozwiązanie.

Wtedy problem został rozwiązany.

W moim przypadku wystąpił błąd, ale nie został on poprawnie przeanalizowany przez VS i pokazany w oknie „Lista błędów”. Aby go znaleźć, często przeglądasz stare „Wyjście” z okna kompilacji i analizujesz komunikaty, zaczynając od góry do dołu, i rozwiązujesz rzeczywisty błąd. M $, napraw! To ogromna strata czasu kolektywnych twórców światów.

Sprawdź dokładnie nazwę folderu projektu. W moim przypadku folder projektu został nazwany ze spacjami. Kiedy sklonowałem projekt z Team Foundation Server przy użyciu git bash, spacje w nazwie folderu zostały przekonwertowane na: „% 20”. Zmiana ich z powrotem na przestrzenie rozwiązała problem.

Miałem ten problem z rozwiązaniem zawierającym wiele projektów.

Pochodzi z powielenia pliku .csproj i dodania kopii do rozwiązania. Plik .csproj zawiera <ProjectGuid>element. Ustawiłem GUID kopiowanego projektu na nowy.

Aktualizacja: Który identyfikator GUID używasz, nie ma znaczenia, po prostu musi się różnić od identyfikatora GUID innego projektu. Możesz utworzyć nowy identyfikator GUID z poziomu programu Visual Studio: Tools -> Create GUIDi skopiować część między nawiasami klamrowymi, tj {...}. Użyj tego jako nowej wartości dla <ProjectGuid>elementu.

Wykonałem również następujące kroki (niekoniecznie konieczne, ale nie bolą):

1. Zamknij rozwiązanie
2. Usuń folder bin
3. Usuń wszystkie foldery obj
4. Otwórz rozwiązanie i buduj

Rozwiązuję ten problem, wykonując następujące kroki:

1. Czyste rozwiązanie
2. Zamknij program Visual Studio
3. Usuwanie / bin z katalogu projektu
4. Uruchom ponownie program Visual Studio
5. Odbuduj rozwiązanie

Mam ten sam problem, problem polegał na tym, że ścieżka rozwiązania ma spacje w nazwie i vs z jakiegoś powodu nie rozwiązuje pakietu ... ponownie pobierz moje repozytorium po prostu zmieniając nazwę rozwiązania bez spacji w nazwie.

na przykład:

/Repo/Project Name/src

Powinien być

/Repo/ProjectName/src

U mnie sprzątanie i budowanie nie działały. Rozładowanie projektu nie zadziałało. Ponowne uruchomienie programu Visual Studio lub nawet komputera nie działało. Oto, co zadziałało:

Przejdź do każdego z projektów, które generują błąd, aw References usuń odwołanie do problematycznego projektu i dodaj je ponownie. To rozwiązuje problem.

Wydaje się, że problem jest związany z przenoszeniem projektu (na przykład przenieś go do folderu), a następnie innego projektu, który się do niego odwołuje, ma nieprawidłową ścieżkę i nie może go znaleźć.

Miałem ten sam problem, nawet przy braku innych błędów wyświetlanych w widoku „Lista błędów” po „Odbuduj rozwiązanie”. Jednak w widoku „Wyjście” zobaczyłem błąd, który był przyczyną problemu:

Nie można rozwiązać podstawowego odwołania „C: ... \ myproj.dll”, ponieważ zostało ono utworzone w oparciu o środowisko „.NETFramework, Version = v4.6.1”. To jest nowsza wersja niż aktualnie docelowa platforma „.NETFramework, Version = v4.5”

Gdy to poprawiłem, problem został rozwiązany.

Inną rzeczą, którą należy sprawdzić, jest platforma docelowa wszelkich projektów, do których istnieją odniesienia, aby upewnić się, że projekt wywołujący używa tej samej lub nowszej wersji platformy.

Miałem ten problem, wypróbowałem wszystkie sugerowane wcześniej odpowiedzi, a następnie z pewnym przeczuciem sprawdziłem ramy. Jeden z przywoływanych projektów był ukierunkowany na 4.6.1, gdy projekt wywołujący był tylko 4.5.2.

Uruchomienie tego polecenia w bash, aby usunąć wszystkie pojemniki, działało dla mnie

$ find . -iname "bin" -o -iname "obj" | xargs rm -rf

Nie mogę jednak zagwarantować, że zadziała dla nikogo innego

Pamiętaj również, że spowoduje to usunięcie wszystkich plików bin - więc będziesz musiał odbudować wszystkie projekty. Oczywiście najlepiej jest przejść do odpowiedniego katalogu przed jego użyciem.

Czyszczenie mojego rozwiązania spowodowało ten problem w programie Visual Studio 2017. Zwolnienie / ponowne załadowanie projektów lub dalsze czyszczenie nie miało żadnego znaczenia. Jedyną rzeczą, która zadziałała, było zamknięcie i ponowne uruchomienie programu Visual Studio.

Sprawdź, czy wszystkie projekty są załadowane. W moim przypadku jeden z projektów został wyładowany, a ponowne załadowanie projektu usuwa błędy.

W moim przypadku musiałem otworzyć plik .csproj i dodać odwołanie ręcznie, w ten sposób (brakowało Microsoft.Extensions.Identity.Stores.dll):

<Reference Include="Microsoft.Extensions.Identity.Stores">
  <HintPath>..\..\..\..\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.identity.stores\2.0.1\lib\netstandard2.0\Microsoft.Extensions.Identity.Stores.dll</HintPath>
</Reference>

Zamknij program Visual Studio, znajdź plik suo rozwiązania, usuń go, ponownie otwórz program Visual Studio.

Co mi pomogło:

Konsola menedżera pakietów (społeczność programu Visual Studio 2019):

Install-Package NuGet.CommandLine
nuget locals all -clear

Odbuduj rozwiązanie.

W moim przypadku napotkałem ten sam błąd. Jednym z moich rozwiązań projektowych było odwoływanie się do zestawu z innej lokalizacji NuGet. Właśnie zmieniłem to na poprawną lokalizację, aby rozwiązać ten błąd i odbudować. i wow projekt został pomyślnie skompilowany, a wszystkie inne błędy zniknęły.

Miałem ten sam błąd. W moim przypadku zbudowałem bibliotekę (nazwij ją commsLibrary), która odwołuje się do innych bibliotek, włączając je jako projekty w moim rozwiązaniu. Później, kiedy budowałem projekt i dodałem moją commsLibrary , za każdym razem, gdy budowałem, otrzymałem plik metadanych nie można znaleźć błędu. Dodałem więc biblioteki, do których odwołuje się moja biblioteka komunikacyjna do bieżącego projektu, a następnie udało się ją zbudować.

Po zmierzeniu się z tak wieloma problemami, oto rozwiązanie, które znalazłem.

1. otwórz folder swojego projektu.
2. znajdź Your_Project_Name.csproj [plik projektu Visual C # (.csproj)]

3. otwórz ten plik w dowolnym edytorze tekstu i znajdź brakujący plik ItemGroup.

   <ItemGroup> <None Include="..." /> </ItemGroup>

4. usuń tę ItemGroup i ponownie otwórz projekt i skompiluj

5. Jeśli to odniesienie jest dla Ciebie ważne, dodaj ponownie.

Miałem ten sam problem i próbowałem rozwiązań z pliku metadanych „.dll” nie można znaleźć

ale żaden z nich nie działał.

Więc po próbach i błędach naprawiłem to, rozładowując i ponownie ładując projekt, wykonując to, zresetuj plik konfiguracyjny i naprawiłem problem.

Z 25 projektów zbudowałem 10 projektów w rozwiązaniu pojedynczo na podstawie zależności. Następnie zbuduj rozwiązanie. Naprawiło to dla mnie

Miałem ten sam problem. Mój problem polegał na tym, że ktoś inny z zespołu przeniósł folder zajęć, a projekt go szukał.

U mnie były 44 błędy; 43 kończyło się na .dll (szukanie zależności), a pierwszy na liście błędów kończył się na .cs (szukanie właściwej klasy). Próbowałem zbudować na czysto i wyczyścić, wyładować, załadować ponownie, zbudować, ale nic nie działało. Skończyło się na tym, że znalazłem klasę w projekcie i po prostu ją usunąłem, ponieważ i tak była wyświetlana jako niedostępna, po czym nastąpiła czysta kompilacja.

To mi wystarczyło! Mam nadzieję że to pomoże.

Miałem 2 pliki (i 2 klasy) w tym samym projekcie o tej samej nazwie.

W moim przypadku usunąłem jeden plik bezpośrednio z menu git eksploratora zespołu, który powodował ten problem. Kiedy sprawdzałem eksplorator rozwiązań, nadal pokazywał usunięty plik jako plik bez odniesienia. Po usunięciu tego pliku z eksploratora rozwiązań mogłem pomyślnie zbudować projekt.

U mnie zadziałało:

Odinstaluj, a następnie ponownie zainstaluj przywoływany pakiet Nuget, w którym występuje błąd.

W moim przypadku uruchomiłem testy i otrzymałem błąd CS0006. Okazało się, że uruchamiam testy w trybie Release. Przejście do trybu debugowania naprawiło ten błąd.

Ten problem występuje, gdy zmieniono nazwę rozwiązania, a platforma .net nie może znaleźć starego rozwiązania.

Aby rozwiązać ten problem, musisz znaleźć i zastąpić starą nazwę rozwiązania i wszystkie związane z nim zależności nową nazwą. Jeśli chcesz przeglądać fizyczny plik za pomocą eksploratora plików, zrób to.

Pliki, których normalnie dotyczy AssemblyInfo.cs, .slnto Properties > Application > Assemblynazwa i domyślna przestrzeń nazw. Pamiętaj, aby zaktualizować je pod nową nazwą.

Otwórz eksplorator plików, jeśli folder o starej nazwie nadal istnieje, musisz go usunąć. Następnie wyczyść i skompiluj rozwiązanie, aż błąd zniknie. (W razie potrzeby wyczyść i zbuduj projekt jeden po drugim, szczególnie projekt, którego dotyczy problem).

W moim przypadku problem polegał na tym, że odwoływałem się do projektu, w którym skomentowałem wszystkie .cspliki.

Na przykład ProjectApp odwołuje się do ProjectUtility. W ProjectUtility miałem tylko 1 .csplik. Już go nie używałem, więc skomentowałem cały plik. W ProjectApp nie wywoływałem żadnego kodu z ProjectUtility, ale miałem using ProjectUtility;w jednym z .csplików ProjectApp . Jedynym błędem jaki otrzymałem od kompilatora był błąd CS0006 .

Odkomentowałem plik .cs plik w ProjectUtility a błąd odszedł. Więc nie jestem pewien, czy brak kodu w projekcie powoduje, że kompilator tworzy nieprawidłowy zestaw, czy w ogóle nie generuje biblioteki DLL. Rozwiązaniem dla mnie było po prostu usunięcie odniesienia do ProjectUtility zamiast komentowania całego kodu.

Jeśli zastanawiałeś się, dlaczego skomentowałem cały kod z projektu, do którego się odwołujesz, zamiast usuwać odniesienie, zrobiłem to, ponieważ coś testowałem i nie chciałem modyfikować ProjectApp.csprojpliku.