Błąd „Nie można znaleźć pliku metadanych„… \ Release \ project.dll ”w programie Visual Studio”

Niedawno zacząłem otrzymywać tę wiadomość losowo:

Nie można znaleźć pliku metadanych „... \ Release \ project.dll” w programie Visual Studio

Mam rozwiązanie zawierające kilka projektów. Bieżący tryb kompilacji to debugowanie, a konfiguracje wszystkich projektów są ustawione na debugowanie. Ale kiedy próbuję uruchomić główny projekt - czasami pojawia się kilka błędów, z których wszystkie to „Plik metadanych” ... \ Release \ projectX.dll 'nie może zostać znaleziony ”- i, spójrz, mówi o RELEASE folderu, chociaż bieżący tryb to Debug. Czemu? Próbowałem znaleźć odniesienie do „Release \ projectX.dll” we wszystkich plikach rozwiązań i znalazłem je w pliku ResolveAssemblyReference.cache.

Dobrze wyszukałem w Internecie i znalazłem kilka osób z podobnym problemem, ale nie było rozwiązania, a przynajmniej żadnego działającego rozwiązania.

Próbowałem usunąć odniesienia do tych projektów i je przeczytać, ale za jakiś czas ponownie zacznę otrzymywać te błędy.

Wygląda na błąd. Dlaczego wyszukuje projekty, do których istnieją odwołania, w folderach wersji, kiedy zawsze używam trybu debugowania?

PS. Dla tych, którzy napotkali ten problem: nie mogłem go rozwiązać w łatwy sposób. Zniknął dopiero po ponownej instalacji systemu Windows :(

Każdy ma rację ... spróbuj wszystkiego ... (w kolejności od straconego czasu do dużo)

1. Czy masz zły kod? Najpierw napraw to.
2. Czyste rozwiązanie i uruchom ponownie program Visual Studio
3. Usuń / dodaj odniesienia
4. Sprawdź swoje zamówienie kompilacji z większymi projektami i zweryfikuj
5. Ręcznie przebuduj podprojekty
6. Ręcznie kopiuj biblioteki DLL między projektami do powiązanych folderów bin
7. Idź po kawę, zagraj w pinballa i wróć jutro ... w międzyczasie możesz pomyśleć o czymś innym.

Miałem dokładnie ten sam problem. Duże rozwiązanie dla studia wizualnego z ponad 50 projektami.

Wszystkie referencje zostały dodane jako projekty. Kolejność budowania projektu była poprawna (kliknij prawym przyciskiem myszy projekt i wybierz kolejność budowania).

Jednak podczas budowania niektórych projektów wyższego poziomu, projekt „główny”, od którego zależały, nie został zbudowany.

Problem polegał na tym, że te projekty nie zostały wybrane do kompilacji w bieżącej konfiguracji (nie wiem, jak to się stało).

Aby to sprawdzić, wybierz „Configuration Manager” (menu Build) i sprawdź, czy problematyczne projekty są ustawione na kompilację.

Kiedy mówisz, że usunąłeś odniesienia do tych projektów i ponownie je dodałeś, jak dokładnie je ponownie dodałeś? Czy używasz karty „Przeglądaj” w oknie dialogowym „Dodaj odwołanie” w programie Visual Studio? A może korzystałeś z zakładki „Projekty” (która zawiera listę sąsiednich projektów w Twoim rozwiązaniu)?

Edycja : jeśli użyjesz karty „Przeglądaj” i ręcznie dodasz odwołanie do pliku .dll, który znajduje się w folderze / Release, program Visual Studio zawsze będzie szukał pliku .dll w tej lokalizacji, niezależnie od tego, w jakim trybie jesteś obecnie w (Debug lub Release).

Jeśli usunąłeś rzeczywisty plik .dll z folderu Release (ręcznie lub za pomocą „Czystego rozwiązania”), odwołanie zostanie przerwane, ponieważ plik .dll nie istnieje.

Proponuję usunąć odwołanie do ProjectX.dll i dodać je ponownie - ale tym razem użyj zakładki „Projekty” w oknie dialogowym „Dodaj odniesienie”. Po dodaniu odwołania w ten sposób program Visual Studio wie, skąd pobrać odpowiedni plik dll. Jeśli jesteś w trybie debugowania, pobierze go z folderu / Debug. W trybie Release folder / Release. Błąd kompilacji powinien zniknąć, a także nie będziesz już (nieprawidłowo) odwoływać się do pliku Release .dll w trybie debugowania.

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

Sekcja 1):

W rozwiązaniach ogólnych:

Wystąpiły 4 tego rodzaju błędy („nie można znaleźć pliku metadanych”) oraz 1 błąd z informacją „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 VS i spróbuj ponownie zbudować.

2. Przejdź do „Eksploratora rozwiązań” . Kliknij prawym przyciskiem myszy Rozwiązanie. Przejdź do Właściwości . Przejdź do „Configuration Manager” . Sprawdź, czy pola wyboru w obszarze „Kompilacja” są zaznaczone, czy nie. Jeśli którekolwiek lub wszystkie są odznaczone, sprawdź je i spróbuj ponownie zbudować.

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

4. Buduj kolejność i zależności projektu:

   Przejdź do „Eksploratora rozwiązań” . Kliknij prawym przyciskiem myszy Rozwiązanie. Przejdź do „Zależności projektu ...” . Zobaczysz 2 zakładki: „Zależności” i „Kolejność budowy” . Ta kolejność kompilacji to ta, w której kompiluje się rozwiązanie. Sprawdź zależności projektu i kolejność kompilacji, aby zweryfikować, czy jakiś projekt (powiedzmy „projekt1”), który jest zależny od innego (powiedzmy „projekt2”), próbuje zbudować przed tym (projekt2). Może to być przyczyną błędu.

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

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

   Jeśli to jest przyczyna, dostosuj kolejność budowania.

   ---

Sekcja (2):

Mój konkretny przypadek:

Wypróbowałem wszystkie powyższe kroki z różnymi permutacjami i kombinacjami z kilkakrotnym ponownym uruchomieniem VS. Ale to mi nie pomogło.

Postanowiłem więc pozbyć się innego błędu, na który się natknąłem („Nie można otworzyć pliku źródłowego („ Nieokreślony błąd ”)”).

Trafiłem na bloga: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539

Wypróbowałem kroki wymienione na tym blogu i pozbyłem się błędu „Nie można otworzyć pliku źródłowego („ Nieokreślony błąd ”)” i, co zaskakujące, pozbyłem się również innych błędów („nie można znaleźć pliku metadanych”) .

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

Miałem już ten problem i jedynym sposobem, w jaki udało mi się go rozwiązać, jest uruchomienie Clean Solution, a następnie ponowne uruchomienie programu Visual Studio.

Dla mnie jest to zwykle wyłączony framework docelowy (4.5.2 zamiast 4.6) Jeśli naprawisz strukturę docelową projektu, aby pasowała do struktury docelowej rozwiązania i skompilujesz, zostanie utworzony nowy .dll.

Otwórz ponownie program Visual Studio jako administrator.

Większość odpowiedzi mówi, że musisz usunąć biblioteki swojego rozwiązania, to prawda, ale po ponownym dodaniu bibliotek błąd zostanie ponownie wyświetlony. Musisz sprawdzić, czy wszystkie biblioteki, do których się odwołujesz, mają kompatybilną strukturę .net z platformą .net Twojego rozwiązania. Następnie napraw wszystkie błędy w kodzie i odbuduj rozwiązanie.

Czy sprawdziłeś ustawienia menedżera konfiguracji? W prawym górnym rogu okna dialogowego ustawień projektu.

Czasami zdarza się, że między wszystkimi wpisami wydania pojawia się wpis debugowania. Jeśli tak, to zależność automatyczna utworzona przez wykres zależności rozwiązania jest pomieszana.

Widziałem również ten błąd w rozwiązaniach, w których mam wiele projektów (zwykle projekty netTiers, w których zaktualizowałem jeden lub więcej podprojektów, aby były ukierunkowane na framework 4.0). Usunięcie może być problematyczne. Często można go jednak rozwiązać, najpierw naprawiając wszystkie inne błędy w podprojektach (np. Wszelkie brakujące odniesienia), indywidualnie przebudowując te podprojekty, a następnie usuwając / dodając z powrotem wszelkie odniesienia do tych podprojektów w programie Visual Studio. Osobiście nie miałem szczęścia w rozwiązaniu tego błędu poprzez samo wyczyszczenie roztworu.

Niedawno napotkaliśmy ten problem po aktualizacji do Office 2010 z Office 2007 - musieliśmy ręcznie zmienić odwołania w naszym projekcie do wersji 14 Office Interops, których używamy w niektórych projektach.

Mam nadzieję, że to pomoże - zajęło nam to kilka dni.

W moim przypadku było to spowodowane dwiema czynnikami (VS.2012):

1) Jeden z projektów został skonfigurowany dla AnyCPU zamiast x86

2) Projekt, do którego się odwołano, miał odznaczone pole wyboru „Kompiluj”.

Sprawdź swoją kompilację | Configuration Manager, aby uzyskać przegląd tego, co jest budowane i dla jakiej platformy. Upewnij się również, że zaznaczyłeś to dla debugowania i wydania, ponieważ mogą mieć różne ustawienia.

W moim przypadku miałem kilka błędów w moim kodzie. Program Visual Studio pokazał błąd, który wystąpił zamiast rzeczywistych błędów, takich jak błędy składniowe lub nieznane nazwy klas. Spróbuj wyczyścić roztwór i zbudować projekt po projekcie. W ten sposób odkryjesz rzeczywiste błędy.

Ponownie, właśnie to jest przyczyną błędu u mnie .

Miałem ten problem i zajęło mi dużo czasu, aby go rozgryźć. Problem pojawił się, gdy usunąłem projekty z rozwiązania i zastąpiłem je pakietami nuget.

Rozwiązanie wydawało się w porządku, ale plik .csproj nadal zawierał te projekty wiele razy jako odniesienie.

Wygląda na to, że VS nie czyści odpowiednio tego pliku. Wciąż odwoływał się do usuniętych projektów pod maską. Po ręcznym usunięciu odniesień z pliku csproj wszystko działa ponownie! wohoo

Ten problem jest spowodowany plikami pdb lub CodeContracts.

Aby to rozwiązać:

1. Wyczyść folder wyjściowy i odbuduj rozwiązanie.

2. Skonfiguruj ponownie CodeContracts lub wyłącz je na potrzeby tymczasowej kompilacji.

Mamy ten problem dość często, ale tylko z odwołaniami do projektów C ++ / CLI z projektów C #. Jest to oczywiście błąd głęboko w programie Visual Studio, którego Microsoft postanowił nie naprawiać, ponieważ jest „zbyt złożony” i obiecał przegląd systemu kompilacji C ++, który jest teraz przeznaczony dla Visual Studio 2010.

To było jakiś czas temu i być może poprawka trafiła nawet do Visual Studio 2008; Nie sprawdzałem już tego. Jednak naszym typowym obejściem było

• Konfiguracja przełącznika
• Uruchom ponownie program Visual Studio
• Zbuduj rozwiązanie

Sam miałem ten sam problem.

Visual Studio 2013 poinformowało mnie tylko, że nie może się do niego odwołać i nie może znaleźć metadanych. Kiedy otworzyłem moje rozwiązanie (które zawiera wiele projektów), powiedziałem, że korzystam z projektów niższych niż wersja ramowa jednego z moich projektów.

Więc przełączyłem wszystko na wersję 4.5 i znowu zadziałało.

Wydaje mi się, że kilka miesięcy temu miałem podobny problem. Rozwiązałem to tymczasowo, kopiując wspomnianą bibliotekę DLL do folderu Release, spełniając w ten sposób oczekiwania programu Visual Studio. Później odkryłem odwołanie do biblioteki DLL wydania w moim rzeczywistym kodzie. Powinieneś spróbować przeszukać cały projekt w poszukiwaniu \ release \ project.dll.

Zauważyłem również, że projekty testów jednostkowych programu Visual Studio czasami umieszczają atrybut „DeploymentItem” na każdej z metod testowych wskazujących na docelową bibliotekę DLL, a jeśli przełączysz się między debugowaniem a wydaniem, program Visual Studio może się pomylić, jeśli biblioteka DLL nie jest już w oczekiwanym miejscu. Z mojego doświadczenia wynika, że ​​te atrybuty można bezpiecznie usunąć, jeśli nie umieściłeś ich tam samodzielnie w ramach scenariusza „pojedynczego wdrożenia”.

Miałem ten problem i było to spowodowane nieprawidłową metodą w naruszającej bibliotece (dll), która nie zwróciła wartości, np.

public bool DoSomething()
{
   //I never bothered putting code here....

}

Kiedy to wydałem, wszystko skompilowane :)

Czasami VS2010 przełącza moją konfigurację z dowolnego procesora na platformy mieszane. W takim przypadku pojawia się ten komunikat o błędzie.

Aby rozwiązać ten problem, przełączam się z powrotem na Dowolny procesor:
1. Kliknij rozwiązanie prawym przyciskiem myszy i wybierz właściwości.
2. Kliknij Właściwości konfiguracji, a następnie przycisk Menedżer konfiguracji….
3. W obszarze Platforma aktywnych rozwiązań wybierz Dowolny procesor

Zauważyłem, że zwykle zdarza mi się to, gdy nadal mam deklarację metody w interfejsie, którą klasa implementuje, ale którą później usunąłem i zapomniałem usunąć ją również z interfejsu. Zwykle po prostu zapisuję całe rozwiązanie co 30 minut n, a następnie wracam do wcześniejszej wersji, jeśli nie mogę znaleźć błędu.

Skończyło się na usunięciu moich odniesień (dodałem je poprawnie za pomocą zakładki projektów, a one budowały dobrze), ręcznie edytując moje pliki .csproj i usuwając dziwne wpisy, które nie pasowały - i ustawiając moje wyjścia do debugowania i release, x86 i x64 oraz każdy procesor, który ma być "\ bin" - raz go zbudowałem, potem ponownie dodałem referencję (ponownie, używając zakładki projekty) i wszystko zaczęło znowu działać. W ogóle nie trzeba było ponownie uruchamiać programu Visual Studio.

Dla mnie było to spowodowane przepisaniem celu kompilacji, aby nie wyświetlał biblioteki dll. Usunięcie tego, aby powrócić do domyślnego celu kompilacji, rozwiązało problem.

w moim przypadku pracowałem na branch off master. więc sprawdziłem gałąź główną, uruchomiłem kompilację, a następnie sprawdziłem gałąź. To rozwiązało problem. Jeśli jesteś już na master, sugeruję sprawdzenie poprzedniego zatwierdzenia, a następnie zbudowanie go.

Wydaje się, że dzieje się tak, gdy kupujesz rozwiązanie z wieloma projektami, które mają między sobą odniesienia, a nie zbudowałeś go wcześniej. Jeśli masz odniesienia bezpośrednio do bibliotek dll, zamiast odwoływania się do projektu, otrzymasz ten komunikat. Aby dodać odwołanie do projektu w tym samym rozwiązaniu, należy zawsze używać karty Projekty w oknie dialogowym Dodaj odwołanie. W ten sposób VS może znać prawidłową kolejność tworzenia rozwiązania

to samo przytrafiło mi się dzisiaj, jak opisał Vidar.

Mam błąd kompilacji w bibliotece pomocniczej (do której odwołują się inne projekty) i zamiast powiedzieć mi, że wystąpił błąd w bibliotece pomocniczej, kompilator wyświetla listę błędów typu MetaFile-not-found. Po naprawieniu błędu kompilacji w bibliotece pomocniczej błędy MetaFile zniknęły.

Czy jest jakieś ustawienie w VS, aby to poprawić?

Miałem ten sam problem. Zauważyłem, że mój kontekst db (EF4), który znajdował się w dll projektu, nie został z jakiegoś powodu rozpoznany. Usunąłem go i zamiast tego utworzyłem inny. i to rozwiązało problem.

Miałem dzisiaj ten sam problem.

Moja aplikacja, aplikacja Windows Forms, przypadkowo miała odniesienie do siebie. Dziwne.

Po usunięciu błąd zniknął.

Odwołanie było dodawane za każdym razem, gdy przeciągałem kontrolkę użytkownika, znajdującą się w samym projekcie Windows Forms, do formularza.

Miałem ten sam problem. Ręczne usuwanie i dodawanie bibliotek dll nie pomogło. Biblioteki ClassLibraries nie skompilowały się dla wszystkich projektów i brakowało ich w folderze ... \ bin \ Debug projektu [ponieważ przez pomyłkę wyczyściłem rozwiązanie]. Ponieważ biblioteka klas nie została skompilowana, oznacza to, że w jednym z tych podprojektów mogą występować błędy .

Rozwiązanie: Ponieważ moje biblioteki dll były w folderze ... \ bin \ Release , próbowałem odbudować w trybie wydania i znalazłem błąd w jednym wierszu w jednym z podprojektów. Usunięcie błędu i odbudowanie rozwiązania pozwoliło usunąć błąd kompilacji.

Dla mnie Visual Studio utworzyło nazwę projektu.v11 typu „Opcje użytkownika rozwiązania Visual Studio”. Usunąłem ten plik i uruchomiłem ponownie i wszystko było w porządku.