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


135

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 :(


Pierwszą rzeczą, jaką należy wykonać w przypadku takich problemów, jest usunięcie pliku .suo i jego przebudowa.
wentylacja

ten problem może wystąpić, jeśli dll, do której istnieje odwołanie, używa innej (niższej) wersji .NET Framework
m4ngl3r

Ciągle występował ten problem, dopóki nie wyłączyłem równoległych kompilacji. Myślę, że jest błąd w sprawdzaniu zależności kompilacji równoległej, prawdopodobnie związany z buforowaniem nieaktualnych informacji. (Dla przypomnienia, teraz używam kompilacji równoległych i po prostu buduję ponownie, jeśli wystąpi problem, co zwykle działa.)
yoyo


Odpowiedzi:


138

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.

17
Musisz wyczyścić wszystkie BŁĘDY i zapewnić stabilne rozwiązania / projekt.
Ravi Ram

Dzieje się tak z powodu różnicy nazw w nazwie folderu i nazwie przestrzeni nazw. Jeśli utworzysz przestrzeń nazw o określonej nazwie, a później zmienisz jej nazwę, przestrzeń nazw będzie miała samą starą nazwę. Kompilacja zajmie starą ścieżkę, aby znaleźć plik .dlli .exe. Aby tego uniknąć, otwórz .csprojplik każdej przestrzeni nazw za pomocą pliku tekstowego i znajdź starą ścieżkę w pliku. usuń to, wyczyść i odbuduj roztwór. To zadziałało dla mnie. Cały dzień spędziłem nad tym problemem.
Sooraj

Jeśli nie odniesiesz sukcesu i zajmuje to trochę czasu, po prostu wróć najpierw do ponownego wypróbowania niektórych podstawowych rzeczy. Zacząłem budować podprojekty, nadal otrzymywałem błędy, ale potem zamknąłem i ponownie otworzyłem VS, przebudowałem rozwiązanie i wszystko działało.
Chris Halcrow

6
Miałem niezgodne nazwy przestrzeni nazw i projektów w domowej dll, do której odwołuje się plik dll. Ponadto został zbudowany z .NET 4.5.2 zamiast 4.5. Człowiek!
Jess

1
Spróbuj usunąć plik .suo. Dość często ulega uszkodzeniu.
Timbo,

21

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


Dziękuję Ci! Wyszło mi to świetnie, gdy z jakiegoś powodu moja konfiguracja wydania nie zbudowała jednego z moich projektów.
Vectovox

Uratowałeś mi życie!
Chethan Shetty

16

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.


Skorzystałem z zakładki "Przeglądaj" w oknie "Dodaj odniesienie"
nightcoder

1
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.
Wes Grant

15

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 .



1
Głosowałem na tę odpowiedź, ponieważ napotkaliśmy ten problem dla współpracownika. Jego system w jakiś sposób stracił większość / wszystkie zależności, więc podczas budowania nie budowałby się we właściwej kolejności, ponieważ „plik metadanych dla„ cokolwiek.dll ”nie istnieje”. Po prostu przeszliśmy przez wszystkie jego projekty z innym systemem, aby zweryfikować wszystkie zależności, których potrzebował w każdym projekcie.
jmbertucci

Dobrze ... Cieszę się, że moja odpowiedź była dla Ciebie pomocna.
Vikram,

11

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.


1
W mojej sytuacji to nie pomaga, po krótkim czasie problem pojawia się ponownie.
nightcoder

To właśnie naprawiło to dla mnie.
splintor

3
Ten też po prostu działał dla mnie. Czyściłem wiele razy i nic nie działało. Po wyczyszczeniu i ponownym uruchomieniu ponownie zaczęło działać. Jakie to irytujące.
Ricky

8

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.


Miałem ten sam problem w przypadku projektu utworzonego w starszej wersji programu Visual Studio. Po zaktualizowaniu VS, projekty zostały utworzone z nowszą wersją .NET i spowodowały problem z nie znalezioną biblioteką DLL. (Przejdź do panelu właściwości projektu, aby wyświetlić / edytować wersję .NET.) Dzięki!
Tony S Yu

Dziękuję milion razy (tyle innych rozwiązań wypróbowałem). To zadziałało. Z jakiegoś powodu biblioteka, którą
dodam,

1
Dodałem nowy projekt biblioteki klas (dll), do którego odwoływano się w kilku innych projektach. Nowa biblioteka dll to .NET Framework 4.8, podczas gdy wszystkie inne projekty to 4.7.2. Zmiana platformy docelowej (we właściwościach projektu) na 4.7.2 naprawiła to dla mnie. Dziękuję Adam!
iCode


3

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.


3

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.


Sprawdziłem to. Wszystkie projekty mają tę samą konfigurację.
nightcoder

2

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.


1
Usunięcie referencji z innych projektów (na przykład mojego interfejsu użytkownika i projektów testowych), naprawienie błędów (w projekcie Core), zbudowanie, a następnie ponowne dodanie tych odwołań załatwiło sprawę.
Ken Pespisa

2

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.


2

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.


2

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 .


2

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


2

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.


2

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

Po tym, jak ten problem zniknie na zawsze czy tylko chwilowo? A co masz na myśli mówiąc o „konfiguracji przełącznika”? Na przykład zawsze używam konfiguracji debugowania. Co powinienem zrobić?
nightcoder

Znika chwilowo. W rzeczywistości może to nie być rozwiązaniem dla Ciebie, jeśli nigdy nie przełączysz konfiguracji między debugowaniem a wydaniem. Lub przełączania, aby zwolnić, a następnie debug może go naprawić, kto wie;)
OutOfMemory

Cóż, kilka dni temu przeszedłem na wydanie, zbudowałem rozwiązanie, a następnie wróciłem do debugowania. Po tym problem się zmutował :): teraz
wyskakuje

2

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.


To było to samo rozwiązanie, do którego doszedłem, mając ten problem. Niektóre odwołania używały Framework wyższego niż moja aplikacja podstawowa, kiedy zmieniłem Framework w aplikacji podstawowej na 4.5.2 (tak samo jak inne odwołania), problem zniknął. Chociaż VS nie powiedział nic o różnych wersjach frameworka ...
NoLifeKing

1

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


1

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 :)


Miałem napisać tę samą odpowiedź, ale zauważyłem, że wspomniałeś już o tym problemie. Miałem ten sam problem, w którym nie zwróciłem wartości logicznej, a komunikat o błędzie dla tego problemu został ukryty wśród ton innych problemów wygenerowanych po fakcie.
gonzobrains

1

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


1

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.


1

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.


1

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.


1

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.


1
Łał! Próbowałem tylu opcji, nic nie działało. Ale to rozwiązało problem! Dzięki kolego :)
Tharindu

0

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


0

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ć?


0

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.


0

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.


0

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.


0

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.

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.