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

Pracuję nad projektem WPF, C # 3.0 i pojawia się ten błąd:

Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem

Oto jak odwołuję się do moich kontrolek użytkownika:

xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>

Dzieje się tak po każdej nieudanej kompilacji. Jedynym sposobem, w jaki mogę uzyskać rozwiązanie do kompilacji, jest skomentowanie wszystkich moich kontrolek użytkownika i przebudowanie projektu, a następnie odkomentowanie kontrolek użytkownika i wszystko jest w porządku.

Sprawdziłem konfiguracje zamówień kompilacji i zależności.

Jak widać, wydaje się, że skrócił bezwzględną ścieżkę do pliku DLL ... Przeczytałem, że jest błąd w długości. Czy to możliwy problem?

Jest to bardzo denerwujące i musi komentować, budować i niekomfortowo, kompilacja staje się niezwykle męcząca.

Właśnie miałem ten sam problem. Visual Studio nie buduje projektu, do którego istnieje odwołanie.

Instrukcje pisemne:

1. Kliknij rozwiązanie prawym przyciskiem myszy i kliknij Właściwości.
2. Kliknij opcję Konfiguracja po lewej stronie.
3. Upewnij się, że pole wyboru w „Kompilacji” dla projektu, którego nie można znaleźć, jest zaznaczone. Jeśli jest już zaznaczone, odznacz, naciśnij Zastosuj i zaznacz pola ponownie.
4. (Opcjonalnie) Trzeba było to zrobić dla obu trybów Zwolnij i Debuguj we właściwościach rozwiązania.

Instrukcje przechwytywania ekranu:

• Mówią, że obraz jest wart tysiąca słów. Kliknij GIF, aby powiększyć, i mam nadzieję, że będzie łatwy do naśladowania:

Może się to nadal zdarzyć w nowszych wersjach programu Visual Studio (właśnie miałem to na Visual Studio 2013):

Inną rzeczą do wypróbowania jest zamknięcie programu Visual Studio i usunięcie .suopliku znajdującego się obok .slnpliku. (Zostanie ponownie wygenerowany następnym razem Save all(lub wyjdziesz z Visual Studio)).

Miałem ten problem podczas dodawania nowych projektów do rozwiązania na innym komputerze, a następnie pobierania poprawek, ale .suoplik może być uszkodzony również w innych przypadkach i prowadzić do bardzo dziwnego zachowania Visual Studio, więc usunięcie go jest jednym z rzeczy, których zawsze próbuję.

Pamiętaj, że usunięcie .suopliku spowoduje zresetowanie projektów startowych rozwiązania.

Więcej na temat .suopliku jest tutaj .

Sugerowana odpowiedź nie działała dla mnie. Błąd jest wabikiem dla innego problemu.

Dowiedziałem się, że celowałem w nieco inną wersję .NET i kompilator oznaczył to jako ostrzeżenie, ale powodowało niepowodzenie budowania. To powinno być oznaczone jako błąd, a nie ostrzeżenie.

Cóż, moja odpowiedź to nie tylko podsumowanie wszystkich rozwiązań, ale oferuje coś więcej.

Sekcja 1):

W ogólnych rozwiązaniach:

Miałem cztery tego rodzaju błędy („nie można znaleźć pliku metadanych”) oraz jeden błąd mówiący „Nie można otworzyć pliku źródłowego („ Nieokreślony błąd ”)”.

Próbowałem pozbyć się błędu „nie można znaleźć pliku metadanych”. W tym celu przeczytałem wiele postów, blogów itp. I stwierdziłem, że te rozwiązania mogą być skuteczne (podsumowując je tutaj):

1. Uruchom ponownie program Visual Studio i spróbuj ponownie zbudować.

2. Przejdź do „Solution Explorer” . Kliknij prawym przyciskiem myszy Rozwiązanie. Idź do Właściwości . Przejdź do „Configuration Manager” . Sprawdź, czy pola wyboru w „Kompilacji” są zaznaczone, czy nie. Jeśli którykolwiek lub wszystkie z nich są odznaczone, sprawdź je i spróbuj ponownie zbudować.

3. Jeśli powyższe rozwiązania nie działają, postępuj zgodnie z sekwencją wymienioną w kroku 2 powyżej, a nawet jeśli wszystkie pola wyboru są zaznaczone, odznacz je, sprawdź ponownie i spróbuj zbudować ponownie.

4. Kolejność budowania i zależności projektu:

   Przejdź do „Solution Explorer” . Kliknij prawym przyciskiem myszy Rozwiązanie. Przejdź do „Zależności projektu ...” . Zobaczysz dwie zakładki: „Zależności” i „Kolejność budowania” . Ta kolejność kompilacji jest kolejnością kompilowania rozwiązania. Sprawdź zależności projektu i kolejność kompilacji, aby sprawdzić, czy jakiś projekt (powiedz „projekt1”), który jest zależny od innego (powiedz „projekt2”), próbuje zbudować przed tym projektem (projekt2). Może to być przyczyną błędu.

5. Sprawdź ścieżkę brakującego pliku .dll:

   Sprawdź ścieżkę brakującego pliku .dll. Jeśli ścieżka zawiera spację lub inny nieprawidłowy znak ścieżki, usuń ją i spróbuj ponownie zbudować.

   Jeśli to jest przyczyną, dostosuj kolejność kompilacji.

Sekcja (2):

Mój szczególny przypadek:

Wszystkie powyższe kroki próbowałem z różnymi kombinacjami i kombinacjami z kilkakrotnym restartowaniem Visual Studio. Ale to mi nie pomogło.

Postanowiłem więc pozbyć się innego napotkanego błędu („Nie można otworzyć pliku źródłowego („ Błąd nieokreślony ”)).

Natrafiłem na post na blogu: Błąd TFS - nie można otworzyć pliku źródłowego („Błąd nieokreślony”)

Próbowałem kroków opisanych w tym wpisie na blogu i pozbyłem się błędu „Nie można otworzyć pliku źródłowego („ Błąd nieokreślony ”)” i, co zaskakujące, pozbyłem się innych błędów („nie można znaleźć pliku metadanych”), ponieważ dobrze.

Sekcja 3):

Morał historii:

Wypróbuj wszystkie rozwiązania wymienione w sekcji (1) powyżej (i wszelkie inne rozwiązania), aby pozbyć się błędu. Jeśli nic nie działa, zgodnie z blogiem wspomnianym w sekcji (2) powyżej, usuń wpisy wszystkich plików źródłowych, które nie są już obecne w kontroli źródła i systemie plików z pliku .csproj .

W moim przypadku było to spowodowane niedopasowaniem wersji .NET Framework.

Jeden projekt miał 3.5, a drugi odnosi się do projektu 4.6.1.

Zamykanie i ponowne otwieranie Visual Studio 2013 działało dla mnie!

Cóż, nic z poprzednich odpowiedzi nie działało dla mnie, więc pomyślałem o tym, dlaczego klikam i mam nadzieję, że jako programiści powinniśmy naprawdę spróbować zrozumieć, co się tutaj dzieje.

Wydawało mi się oczywiste, że to niepoprawne odniesienie do pliku metadanych musi być gdzieś przechowywane.

Szybkie wyszukiwanie pliku .csproj pokazało winne linie. Miałem sekcję o nazwie <itemGroup>, która wydawała się zawieszać na starej niepoprawnej ścieżce pliku.

<ItemGroup>
    <ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
        <Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
        <Name>Beeyp.Entities</Name>
    </ProjectReference>
...

Tak naprawdę prosta poprawka:

1. Wykonaj kopię zapasową pliku .csproj.
2. Znajdź nieprawidłowe ścieżki w pliku .csproj i odpowiednio zmień nazwę.

Upewnij się, że wykonałeś kopię zapasową starego .csproj przed skrzypkiem .

Spotkałem również ten problem. Najpierw musisz ręcznie zbudować swój projekt DLL, klikając prawym przyciskiem myszy opcję Buduj. Wtedy to zadziała.

W moim przypadku mam zainstalowany katalog w błędny sposób.

Jeśli ścieżka rozwiązania jest podobna do „Mój projekt% 2c Bardzo popularny% 2c Testowanie jednostkowe% 2c Oprogramowanie i sprzęt.zip”, nie może rozwiązać pliku metadanych, być może powinniśmy zapobiec nieprawidłowym słowom, takim jak% 2c.

Zmiana nazwy ścieżki na normalną nazwę rozwiązała mój problem.

Otrzymałem ten sam błąd „Nie można znaleźć pliku metadanych” .dll „i próbowałem kilku rzeczy opisanych powyżej, ale przyczyną tego błędu było to, że odwoływałem się do pliku DLL innej firmy, który był skierowany na wersję .NET wyższą że mój projekt jest przeznaczony do wersji .NET. Rozwiązaniem była zmiana docelowej struktury mojego projektu.

Visual Studio 2019 to działało dla mnie:

1. Zamknij Visual Studio
2. Usuń ukryty .vsfolder
3. Ponownie otwórz program Visual Studio i przebuduj rozwiązanie.

Dla mnie próbowałem znaleźć bibliotekę DLL na ścieżce zawierającej projekt, ale przenieśliśmy ją do nowego katalogu. Rozwiązanie miało prawidłową ścieżkę do projektu, ale Visual Studio jakoś wciąż szukało starej lokalizacji.

Rozwiązanie: Zmień nazwę każdego projektu - po prostu dodaj znak lub cokolwiek - a następnie zmień nazwę z powrotem na pierwotną nazwę.

To musi zresetować jakąś globalną pamięć podręczną jakiegoś rodzaju w Visual Studio, ponieważ to usuwa zarówno ten problem, jak i kilka podobnych, podczas gdy rzeczy takie jak Clean nie.

Dodałem nowy projekt do mojego rozwiązania i zacząłem go otrzymywać.

Powód? Projekt, który przyniosłem, był ukierunkowany na inną platformę .NET (4.6 i moje pozostałe dwa to 4.5.2).

Dla mnie miało to miejsce, gdy dołączyłem nowy projekt rozwiązania.

Visual Studio automatycznie wybiera .NET Framework 4.5.

Zmieniłem na wersję .NET 4.5.2, podobnie jak inne biblioteki, i działało.

Dla mnie zadziałały następujące kroki:

• Znajdź projekt, który się nie buduje
• Usuń / dodaj odniesienia do projektów w ramach rozwiązania.

Z tym problemem również wyciągałam włosy, ale po wypróbowaniu poprzednich odpowiedzi jedyną rzeczą, która działała dla mnie, było otwarcie każdego projektu w moim rozwiązaniu 1 na 1 i zbudowanie go indywidualnie.

Następnie zamknąłem program Visual Studio 2013, ponownie otworzyłem moje rozwiązanie i zostało poprawnie skompilowane.

To dziwne, ponieważ jeśli kliknąłem każdy projekt w Eksploratorze rozwiązań i próbowałem je zbudować w ten sposób, wszystkie zawiodły. Musiałem otworzyć je same w ich własnych rozwiązaniach.

Wygląda na tego rodzaju błędy związane z faktem, że Visual Studio nie podaje poprawnych informacji o błędzie. Deweloper nie rozumie nawet przyczyny niepowodzenia kompilacji. Może to być błąd składniowy lub coś innego. Często, aby rozwiązać takie problemy, powinieneś znaleźć źródło problemu (na przykład spójrz na dziennik kompilacji).

W moim przypadku problemem było to, że Error Listokno nie wyświetlało żadnych błędów. Ale tak naprawdę były błędy składniowe; Znalazłem te błędy w Outputoknie, a po ich naprawieniu problem został rozwiązany.

Moje wystąpienie problemu było spowodowane wspólnym projektem, który miał zduplikowaną nazwę klasy (pod inną nazwą). To dziwne, że Visual Studio nie mógł tego wykryć i zamiast tego po prostu wysadził proces kompilacji.

Mam ten problem w Visual Studio 2012 w rozwiązaniu, które miało wiele projektów. Ręczne przebudowanie każdego projektu w rozwiązaniu w tej samej kolejności, co zamówienie kompilacji projektu (kliknij prawym przyciskiem myszy i przebuduj w Solution Explorer) naprawiło to dla mnie.

W końcu doszedłem do takiego, który dał mi błąd kompilacji. Naprawiłem błąd, a po tym rozwiązanie będzie działać poprawnie.

W moim przypadku problem polegał na tym, że ręcznie usunąłem plik niekompilacyjny, który został oznaczony jako „brakujący”. Kiedyś usunąłem odniesienie do brakującego pliku i ponownie skompilowałem - wszystko poszło dobrze.

Jeśli w nazwie rozwiązania znajduje się spacja, spowoduje to również problem. Usunięcie spacji z nazwy rozwiązania, aby ścieżka nie zawierała% 20, rozwiąże ten problem.

Wracając do tego kilka lat później, ten problem jest bardziej niż prawdopodobnie związany z maksymalnym limitem ścieżki systemu Windows:

Nazewnictwo plików, ścieżek i przestrzeni nazw , ograniczenie maksymalnej długości ścieżki

W moim przypadku problem był spowodowany prostym błędem kompilacji,

błąd CS0067: Zdarzenie „XYZ” nigdy nie jest używane

z jakiegokolwiek powodu nie pojawił się w oknie błędu.

Z tego powodu system kompilacji Visual Studio wydawał się nie zauważać błędu i próbował budować projekty zależne, co z kolei zakończyło się niepowodzeniem z irytującym komunikatem o metadanych.

Zalecenie jest -głupie, jak może to zabrzmieć-:

Najpierw spójrz na okno wyjściowe !

Zajęło mi to pół godziny, zanim ten pomysł mnie uderzył ...

Ja też miałem ten sam błąd. Ukrywa się jak na poniższej ścieżce. Ścieżka, o której mówiłem dla pliku DLL, to „D: \ Assemblies Folder \ Assembly1.dll”.

Ale oryginalna ścieżka, do której odwoływał się zespół, brzmiała „D: \ Assemblies% 20Folder \ Assembly1.dll”.

Z powodu tej zmiany nazwy ścieżki zestaw nie mógł zostać pobrany z oryginalnej ścieżki i dlatego zgłasza błąd „Nie znaleziono metadanych”.

Rozwiązaniem jest pytanie Przepełnienie stosu Jak zamienić wszystkie spacje na% 20 w C #? .

Napotkałem ten sam problem. W moim przypadku odwołałem się do projektu biblioteki klas z wyższą wersją .Net niż mój projekt, a VS nie zbudował projektu i zgłosił ten sam błąd, który opublikowałeś.

Po prostu ustawiłem wersję .Net mojego projektu biblioteki klas (ten, który zepsuł kompilację) identyczną z wersją .Net projektu i rozwiązania problemu.

Wskazując rażąco oczywiste: jeśli nie masz włączonej opcji „Pokaż okno wyjściowe po rozpoczęciu kompilacji”, upewnij się, że zauważysz, że kompilacja kończy się niepowodzeniem (mały błąd „kompilacji nie powiódł się” w lewym dolnym rogu) !!!!

Wystąpił ten błąd podczas próby opublikowania aplikacji internetowej. Okazało się, że jedna z właściwości klasy została zapakowana

#if DEBUG
    public int SomeProperty { get; set; }
#endif

ale wykorzystanie nieruchomości nie było. DEBUGOczywiście publikacja została wykonana w konfiguracji Release bez symbolu.

Na podstawie komunikatu o błędzie nie sądzę, aby ścieżka do pliku została obcięta. Wygląda to po prostu niepoprawnie. Jeśli poprawnie czytam komunikat, wygląda na to, że szuka pliku DLL w ...

WORK = - \ Tools \ VersionManagementSystem \ BusinessLogicLayer \ bin \ Debug \ BusinessLogicLayer.dll

To nie jest poprawna ścieżka. Czy to możliwe, że masz definicję makra w procesie kompilacji ustawioną na niepoprawną wartość?

Miałem ten problem, ponieważ .nuget\NuGet.exenie został uwzględniony w moim repozytorium. Mimo że włączyłem DownloadNuGetExeNuGet.targets, zgłosił błąd serwera proxy podczas próby pobrania. Spowodowało to niepowodzenie pozostałych kompilacji projektu.

Ten błąd może zostać wyświetlony, jeśli używasz fałszywych zestawów. Usuwanie podróbek prowadzi do pomyślnej kompilacji projektu.