plik źródłowy różni się od tego, kiedy moduł został zbudowany

To mnie doprowadza do szału.

Mam dość duży projekt, który próbuję zmodyfikować. Zauważyłem wcześniej, że kiedy piszę DbCommand, Visual Studio nie robi na nim żadnego podświetlania składni i używam System.Data.Common.

Mimo że nic nie było podświetlone, projekt wydawał się działać poprawnie w mojej przeglądarce. Postanowiłem więc uruchomić debugger, aby sprawdzić, czy wszystko działa tak, jak powinno.

Za każdym razem, gdy zostanie wywołana klasa, która nie wykonała podświetlenia, otrzymuję "the source file is different from when the module was built"wiadomość.

Wyczyściłem rozwiązanie i kilka razy je przebudowałem, usunąłem pliki tmp, postępowałem zgodnie ze wszystkimi wskazówkami tutaj. Pobieranie „Plik źródłowy różni się od tego, kiedy moduł był budowany”. , zrestartował serwer WWW i nadal informuje mnie, że pliki źródłowe są inne, chociaż wyraźnie nie są.

Z tego powodu nie mogę przetestować żadnego kodu, który napisałem dzisiaj.

• W jaki sposób źródło może różnić się od pliku binarnego, skoro właśnie je zastosowałem?
• Czy jest jakiś sposób, aby wprowadzić trochę sensu do studia wizualnego, czy po prostu czegoś mi brakuje?

Ten problem wystąpił podczas uruchamiania aplikacji konsolowej, w której źródło, które było inne, było źródłem, które miało punkt wejścia (statyczna pustka główna). Usunięcie katalogów bin i obj i wykonanie pełnej przebudowy zdawało się to korygować, ale za każdym razem, gdy wprowadzałem zmianę w kodzie, znów stawał się nieaktualny.

Powód, który znalazłem to:

1. Zaznaczyłem „Buduj tylko projekty startowe i zależności przy uruchomieniu” (Narzędzia -> Opcje -> Projekty i rozwiązania -> Kompiluj i uruchamiaj)
2. W menedżerze konfiguracji mój projekt startowy nie miał zaznaczonej opcji „Kompiluj”

(Dla # 2 -> dostępne za pośrednictwem paska narzędzi na liście rozwijanej „Debuguj / Zwolnij”).

Miałem ten sam problem, wszystkie moje projekty znajdowały się w tym samym rozwiązaniu, więc korzystały z odniesień z projektu do projektu, więc gdy jeden się zmienił, pozostałe powinny zostać zaktualizowane. Jednak tak nie było, próbowałem zbudować, przebudować, zamknąć VS2010, wyciągnąłem nową kopię z naszej kontroli źródła. Nic z tego nie działało, ostatecznie próbowałem kliknąć projekt prawym przyciskiem myszy i przebudować każdy projekt indywidualnie. To zaktualizowało pliki .dlls i .pdb, dzięki czemu mogłem debugować.

Problem polega na tym, że pliki dll i / lub pdb nie są zsynchronizowane.

Wykonaj poniższe czynności

1. Po prostu usuń katalog bin z projektu, w którym generowana jest biblioteka DLL.
2. Przebuduj projekt.
3. Usuń odwołanie z projektu, które odwołuje się do biblioteki DLL.
4. Dołącz ponownie odniesienie.
5. Cieszyć się.

Oprócz tych odpowiedzi miałem ten sam problem podczas zastępowania nowych bibliotek DLL starymi z powodu złej ścieżki. Jeśli nadal otrzymujesz ten błąd, możesz nie wskazać niewłaściwej ścieżki dla bibliotek DLL. Przejdź do menedżera IIS i kliknij witrynę sieci Web, która korzysta z Twoich bibliotek DLL. W prawym oknie kliknij Ustawienia zaawansowane i przejdź do ścieżki folderu Ścieżka fizyczna w Eksploratorze plików i upewnij się, że używasz tego folderu do zastąpienia bibliotek DLL.

Kilka rzeczy do sprawdzenia:

Czy sprawdziłeś dwukrotnie odniesienia do projektów?

Czy masz nadal uruchomiony serwer sieci Web w programie Visual Studio? Sprawdź zasobnik systemowy i poszukaj strony z ikoną koła zębatego (możesz mieć więcej niż jedną):

_{(źródło: msdn.com )}

Kliknij prawym przyciskiem myszy i zamknij / wyjdź. Możesz mieć więcej niż jeden. Czy możesz teraz debugować swoje zmiany?

Czy używasz wersji do debugowania, ale skompilowałeś tylko wersję wydania (lub odwrotnie)?

Czy kompilacja rzeczywiście się powiodła? Wiem, że kliknąłem opcję „wystąpiły błędy, czy mimo to chcesz kontynuować?” wiadomość kilka razy, nie zdając sobie z tego sprawy.

W przypadku usług internetowych problem może być spowodowany użyciem polecenia programu Visual Studio „Wyświetl w przeglądarce”. Spowoduje to umieszczenie plików DLL i PDB usługi w folderach bin i obj. Podczas przechodzenia do usługi sieci Web z klienta program Visual Studio w jakiś sposób używa PDB w folderze bin (lub obj), ale używa biblioteki DLL w wyjściowym folderze kompilacji projektu. Istnieje kilka obejść:

1. Spróbuj usunąć pliki DLL i PDB z bin usługi internetowej i pliki obj.
2. Spróbuj kliknąć „Wyświetl w przeglądarce” w programie Visual Studio.

Jeśli wcześniej wystąpił błąd niezgodności pliku źródłowego, program Visual Studio mógł dodać nazwę pliku do czarnej listy. Sprawdź właściwości swojego rozwiązania. Wybierz "Właściwości wspólne -> Debuguj pliki źródłowe" po lewej stronie okna dialogowego. Jeśli pliki źródłowe usługi WWW pojawiają się w polu „Nie szukaj tych plików źródłowych”, usuń je.

Właśnie miałem ten problem.

Wypróbowałem wszystkie powyższe, ale tylko to zadziałało:

• Usuń plik .pdb rozwiązania.
• usuń naruszające pliki .obj (w przypadku zgłaszanego pliku z synchronizacją)

zbuduj rozwiązanie.

To rozwiązało problem ze wszystkimi postępami kompilacji.

Oto jak rozwiązałem problem w Visual Studio 2010:

1) Zmień opcję „Konfiguracje rozwiązań” z „Debuguj” na „Zwolnij”

2) Rozpocznij debugowanie

3) Zatrzymaj debugowanie i przełącz opcję „Konfiguracje rozwiązań” z powrotem na „Debuguj”

To zadziałało dla mnie. Krok 3 jest opcjonalny - działał dobrze, kiedy zmieniłem go na „Release”, ale chciałem to zmienić z powrotem.

Moje rozwiązanie:

Dodałem istniejący projekt z innego rozwiązania do nowego pliku rozwiązania.

Nie zauważyłem, że gdy istniejący projekt był przebudowywany, umieszczał końcowe dane wyjściowe w katalogu wyjściowym NOWEGO rozwiązania. Miałem zdefiniowaną ścieżkę konsolidatora, aby zaglądać do katalogu wyjściowego STAREGO rozwiązania.

Przełączenie projektu na wyszukiwanie w katalogu wyjściowym nowego rozwiązania rozwiązało ten problem.

Miałem ten problem i okazało się, że uruchomiłem aplikację konsoli jako aplikację Windows. Przełączenie typu wyjścia z powrotem na konsolę rozwiązało problem.

Miałem ten sam problem. Aby to naprawić, użyłem „trybu wydania” do debugowania w VS2013. Co mi wystarcza, bo pracuję w węźle js \ c ++ addonie.

Zwolnij projekt zawierający plik, który powoduje błąd.

Załaduj ponownie projekt.

Naprawiony

W programie Visual Studio 2017 usunięcie ukrytego folderu vs w rozwiązało ten problem.

Mój problem polegał na tym, że miałem w rozwiązaniu dwa projekty. Drugi był projektem testowym używanym do wywoływania pierwszego. Wybrałem ścieżkę do odniesień z folderu wydania folderu bin.

Więc ilekroć zmieniłem kod pierwszego projektu i przebudowałem go, zaktualizowałem biblioteki dll w folderze debugowania, ale projekt wywołujący wskazywał na folder wydania, dając mi błąd: „plik źródłowy różni się od tego, gdy moduł był zbudowany."

Po usunięciu odniesienia do biblioteki dll głównego projektu w folderze wydania i ustawieniu go na dll w folderze debugowania problem zniknął.

rozwiązanie: - problem polega na tym, że: - jeśli niektóre projekty są w rozwiązaniu, odwołują się do innych projektów, to czasami dll niektórych projektów nie aktualizuje się automatycznie, za każdym razem, gdy budujesz rozwiązanie, niektóre projekty będą miały pliki DLL poprzedniej kompilacji, a nie najnowsze biblioteki dll

musisz przejść ręcznie i skopiować bibliotekę dll najnowszego projektu kompilacji do projektu, do którego się odwołuje

Używałem Visual Studio 2013 i miałem istniejący projekt pod kontrolą źródła.
Pobrałem nową kopię z kontroli źródła do nowego katalogu.
Po wprowadzeniu zmian w nowej kopii, podczas budowania otrzymałem omawiany błąd.

Moje rozwiązanie:
1) Otwórz Documents\IISExpress\config\applicationhost.config
2) Zaktualizuj virtualDirectorywęzeł z katalogiem do nowej kopii i zapisz.

Mój problem polegał na tym, że miałem w projekcie usługę sieciową i zmieniłem ścieżkę kompilacji.

Przywrócenie domyślnej ścieżki kompilacji rozwiązało mój problem.

Miałem ten sam problem i postępowałem zgodnie z większością wskazówek zawartych w innych zamieszczonych tutaj odpowiedziach, ale wydawało mi się, że nic nie działa.

W końcu otworzyłem usługi IIS i ponownie uruchomiłem pulę aplikacji dla mojej aplikacji internetowej. Mam IIS w wersji 8.5.9600, kliknąłem prawym przyciskiem myszy moją aplikację internetową, a następnie: Wdrażanie> Recykling> Recykling puli aplikacji> OK.

Wydaje się, że to rozwiązało problem, teraz punkty przerwania są trafiane zgodnie z oczekiwaniami. Myślę, że zrobienie tego wraz z usunięciem folderów bin i obj pomogło w mojej sytuacji.

Powodzenia!

Wiem, że to stare pytanie, ale miałem ten sam problem i chciałem tutaj opublikować na wypadek, gdyby pomogło to komuś innemu. Mam nowy komputer i dział IT połączył mój stary komputer z nowym. Kiedy konfigurowałem TFS, zamapowałem inną ścieżkę lokalną niż ta, której używałem wcześniej, na dodatkowy dysk wewnętrzny. Stara ścieżka nadal istniała ze scalonych danych na moim dysku twardym, więc mogłem nadal budować i uruchamiać. Moje ścieżki IIS wskazywały również na stary katalog. Po zaktualizowaniu usług IIS do właściwej ścieżki mogłem poprawnie debugować. Usunąłem również stary katalog na dobre.

Ja też tego doświadczyłem. Po prostu otwieram folder obj w projekcie, a następnie otwieram folder debugowania, usuwam plik .pdb i to wszystko.

Ten błąd występuje również, gdy próbujesz wprowadzić zmiany w pliku źródłowym, który nie jest częścią projektu.

Debugowałem metodę z pliku .dll innego z moich projektów, w którym program Visual Studio całkiem pomocnie załadował źródło, ponieważ plik .dll został zbudowany na tej samej maszynie i znało ścieżkę do źródła. Oczywiście zmiana takiego pliku nic nie da, chyba że przebudujesz projekt, do którego się odwołuje.

1. Usuń wszystkie punkty przerwania.
2. Odbudować.
3. Gotowe

W Visual Studio 2015, używając C ++, rozwiązałem the source file is different from when the module was builtproblem

• uruchom ponownie program Visual Studio.

Debuguj-> rozpocznij bez debugowania.

Ta opcja działała dla mnie. Mam nadzieję że to pomoże!

Sprawdź, czy wskazana przez Ciebie lokalizacja przy użyciu mex () w Matlabie jest poprawna (zawiera pliki lib i obj, które są modyfikowane do ostatniej daty kompilacji biblioteki w Visual Studio).

Jeśli tak nie jest:

Upewnij się, że kompilujesz program Visual Studio w trybie, który zapisuje pliki .lib:

1. właściwości -> Właściwości konfiguracji -> Ogólne -> Typ konfiguracji -> Biblioteka statyczna

2. properties -> Config properties -> General -> Target extension = .lib (zamiast exe)

Upewnij się, że katalog wyjściowy i katalog pośredni są zgodne z katalogiem Matlab w

1. właściwości -> Właściwości konfiguracji -> Ogólne -> Katalog wyjściowy
2. właściwości -> Właściwości konfiguracji -> Ogólne -> Katalog pośredni

W moim przypadku odpowiedź @ Eliott nie działa. Aby rozwiązać ten problem, skorzystałem z opcji Wyklucz / Uwzględnij z projektu mój wadliwy plik oraz Wyczyść i odbuduj rozwiązanie.

Po tych czynnościach mój plik z moimi ostatnimi modyfikacjami i debugerem są przywracane.

Mam nadzieję, że to pomoże.

Ten problem pojawia się podczas debugowania czasami w programie Visual Studio, ale gdy aplikacja jest obsługiwana przez IIS . (Musimy rozwijać się w tej formie z kilku skomplikowanych powodów, które mają związek z tym, jak pierwotny programista skonfigurował ten projekt).

Kiedy zmieniam plik i przebudowuję , często to naprawia. Wiem, że to brzmi głupio, ale próbowałem po prostu debugować jakiś kod, aby zobaczyć, dlaczego robi coś dziwnego, skoro nie zmieniłem go od jakiegoś czasu, i wypróbowałem kilkanaście rzeczy z tej strony, ale zostało to naprawione po prostu przez zmianę plik..