Visual Studio 2010 zawsze uważa, że ​​projekt jest nieaktualny, ale nic się nie zmieniło

Mam bardzo podobny problem, jak opisano tutaj .

Uaktualniłem również mieszane rozwiązanie projektów C ++ / CLI i C # z Visual Studio 2008 do Visual Studio 2010. A teraz w Visual Studio 2010 jeden projekt C ++ / CLI zawsze jest nieaktualny.

Nawet jeśli został skompilowany i połączony tuż przed, a jego działanie F5zostało trafione, komunikat „Projekt jest nieaktualny. Czy chcesz go zbudować?” pojawia się. Jest to bardzo denerwujące, ponieważ plik DLL jest bardzo mało warstwowy i zmusza prawie wszystkie projekty rozwiązania do przebudowy.

Moje ustawienia pdb są ustawione na wartość domyślną ( sugerowane rozwiązanie tego problemu ).

Czy to możliwe, aby uzyskać powód, dla którego Visual Studio 2010 wymusza przebudowę lub uważa, że ​​projekt jest aktualny?

Wszelkie inne pomysły, dlaczego Visual Studio 2010 tak się zachowuje?

Tylko dla Visual Studio / Express 2010. Zobacz inne (łatwiejsze) odpowiedzi dla VS2012, VS2013 itp

Aby znaleźć brakujące pliki , skorzystaj z informacji z artykułu Włącz rejestrowanie systemu projektu C ++, aby włączyć rejestrowanie debugowania w programie Visual Studio i pozwól mu powiedzieć, co powoduje przebudowę:

1. Otwórz devenv.exe.configplik (znaleziony w %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\lub w %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\). W przypadku wersji Express plik konfiguracyjny ma nazwę V*Express.exe.config.

2. Dodaj następujący </configSections>wiersz:

   <system.diagnostics>
     <switches>
       <add name="CPS" value="4" />
     </switches>
   </system.diagnostics>
   

3. Uruchom ponownie Visual Studio
4. Otwórz DbgView i upewnij się, że przechwytuje dane debugowania
5. Spróbuj debugować (naciśnij F5 w Visual Studio)

6. Wyszukaj w dzienniku debugowania dowolne wiersze formularza:

   devenv.exe Informacje: 0: Projekt „Bla \ Bla \ Dummy.vcxproj” jest nieaktualny, ponieważ brakuje danych wejściowych kompilacji „Bla \ Bla \ SomeFile.h”.

   (Właśnie nacisnąłem Ctrl + F i szukałem not up to date) To będą odniesienia, które spowodują, że projekt będzie zawsze „nieaktualny”.

Aby to naprawić, usuń wszelkie odniesienia do brakujących plików z projektu lub zaktualizuj odniesienia, aby wskazać ich rzeczywiste lokalizacje.

Uwaga: jeśli używasz wersji 2012 lub nowszej, fragment powinien mieć:

<system.diagnostics>
  <switches>
   <add name="CPS" value="Verbose" />
  </switches>
</system.diagnostics>

W Visual Studio 2012 mogłem łatwiej osiągnąć ten sam wynik niż w przyjętym rozwiązaniu.

Zmieniłem opcję w menu Narzędzia → Opcje → Projekty i rozwiązania → Kompiluj i uruchamiaj → * Szczegółowość budowania projektu MSBuild ”z Minimal na Diagnostyczna .

Następnie w wynikach kompilacji znalazłem te same wiersze, wyszukując „nieaktualny”:

Projekt „blabla” jest nieaktualny. Element projektu „c: \ foo \ bar.xml” ma atrybut „Kopiuj do katalogu wyjściowego” ustawiony na „Kopiuj zawsze”.

To mi się dzisiaj przydarzyło. Udało mi się wyśledzić przyczynę: Projekt zawierał plik nagłówkowy, który już nie istniał na dysku.

Usunięcie pliku z projektu rozwiązało problem.

Natrafiliśmy również na ten problem i dowiedzieliśmy się, jak go rozwiązać.

Problem był taki, jak podano powyżej „Plik nie istnieje już na dysku”.

To nie jest całkiem poprawne. Plik istnieje na dysku, ale plik .VCPROJ odwołuje się do pliku w innym miejscu.

Możesz to „odkryć”, przechodząc do „widoku dołączanego pliku” i klikając kolejno każdy dołączony plik, aż znajdziesz ten, którego Visual Studio nie może znaleźć. Następnie DODAJ ten plik (jako istniejący element) i usuniesz odwołanie, którego nie można znaleźć i wszystko jest w porządku.

Prawidłowe pytanie brzmi: w jaki sposób Visual Studio może nawet budować, jeśli nie wie, gdzie są pliki dołączania?

Uważamy, że plik .vcproj ma jakąś względną ścieżkę do pliku, który nie jest wyświetlany w graficznym interfejsie GUI programu Visual Studio, i to wyjaśnia, dlaczego projekt rzeczywiście się buduje, mimo że widok drzewa dołączeń jest niepoprawny.

Przyjęta odpowiedź pomogła mi znaleźć właściwą drogę do rozwiązania tego problemu dla popieprzonego projektu, z którym musiałem zacząć pracować. Musiałem jednak poradzić sobie z bardzo dużą liczbą złych nagłówków. W przypadku pełnego debugowania danych wyjściowych usunięcie jednego spowodowało zawieszenie się IDE przez 30 sekund podczas wysyłania wyrzutu debugowania, co spowodowało, że proces przebiegał bardzo wolno.

Niecierpliwiłem się i napisałem szybki i brudny skrypt Pythona, aby sprawdzić dla mnie pliki projektu (Visual Studio 2010) i wypisać wszystkie brakujące pliki jednocześnie, wraz z filtrami, w których się znajdują. Można go znaleźć jako Gist tutaj: https://gist.github.com/antiuniverse/3825678 (lub ten widelec, który obsługuje ścieżki względne )

Przykład:

D:\...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj
[Header Files]:
  fx_cs_blood.h   (cstrike\fx_cs_blood.h)
  hud_radar.h   (cstrike\hud_radar.h)
[Game Shared Header Files]:
  basecsgrenade_projectile.h   (..\shared\cstrike\basecsgrenade_projectile.h)
  fx_cs_shared.h   (..\shared\cstrike\fx_cs_shared.h)
  weapon_flashbang.h   (..\shared\cstrike\weapon_flashbang.h)
  weapon_hegrenade.h   (..\shared\cstrike\weapon_hegrenade.h)
  weapon_ifmsteadycam.h   (..\shared\weapon_ifmsteadycam.h)
[Source Files\Swarm\GameUI - Embedded\Base GameUI\Headers]:
  basepaenl.h   (swarm\gameui\basepaenl.h)
  ...

Kod źródłowy:

#!/c/Python32/python.exe
import sys
import os
import os.path
import xml.etree.ElementTree as ET

ns = '{http://schemas.microsoft.com/developer/msbuild/2003}'

#Works with relative path also
projectFileName = sys.argv[1]

if not os.path.isabs(projectFileName):
   projectFileName = os.path.join(os.getcwd(), projectFileName)

filterTree = ET.parse(projectFileName+".filters")
filterRoot = filterTree.getroot()
filterDict = dict()
missingDict = dict()

for inc in filterRoot.iter(ns+'ClInclude'):
    incFileRel = inc.get('Include')
    incFilter = inc.find(ns+'Filter')
    if incFileRel != None and incFilter != None:
        filterDict[incFileRel] = incFilter.text
        if incFilter.text not in missingDict:
            missingDict[incFilter.text] = []

projTree = ET.parse(projectFileName)
projRoot = projTree.getroot()

for inc in projRoot.iter(ns+'ClInclude'):
    incFileRel = inc.get('Include')
    if incFileRel != None:
        incFile = os.path.abspath(os.path.join(os.path.dirname(projectFileName), incFileRel))
        if not os.path.exists(incFile):
            missingDict[filterDict[incFileRel]].append(incFileRel)

for (missingGroup, missingList) in missingDict.items():
    if len(missingList) > 0:
        print("["+missingGroup+"]:")
        for missing in missingList:
            print("  " + os.path.basename(missing) + "   (" + missing + ")")

Usunąłem cpp i niektóre pliki nagłówkowe z rozwiązania (i z dysku), ale nadal miałem problem.

Chodzi o to, że każdy plik używany przez kompilator znajduje się w pliku * .tlog w katalogu tymczasowym. Po usunięciu pliku ten plik * .tlog nie jest aktualizowany. Jest to plik używany przez kompilacje przyrostowe do sprawdzania, czy projekt jest aktualny.

Edytuj ten plik .tlog ręcznie lub wyczyść projekt i przebuduj.

Miałem podobny problem, ale w moim przypadku nie brakowało plików, wystąpił błąd w definicji pliku wyjściowego pdb: zapomniałem sufiksu .pdb (dowiedziałem się przy pomocy metody rejestrowania debugowania).

Aby rozwiązać problem, który zmieniłem, w pliku vxproj następujący wiersz:

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

do

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

Miałem ten problem w VS2013 (aktualizacja 5) i mogą być tego dwa powody, które można znaleźć, włączając „Szczegółowe” wyniki kompilacji w „Narzędzia” -> „Projekty i rozwiązania” -> „Kompiluj i uruchamiaj” .

1. "Forcing recompile of all source files due to missing PDB "..."
   Dzieje się tak, gdy wyłączasz wyjście informacji o debugowaniu w opcjach kompilatora (w ustawieniach projektu: „C / C ++” -> „Format informacji o debugowaniu” na „Brak” i „Linker” -> „Generuj informacje o debugowaniu” na „Nie”:) . Jeśli pozostawiłeś „C / C ++” -> „Nazwa pliku bazy danych programu” domyślnie (czyli „$ (IntDir) vc $ (PlatformToolsetVersion) .pdb”), VS nie znajdzie pliku z powodu błędu ( https : //connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds ).
   Aby to naprawić, po prostu wyczyść nazwę pliku na „” (puste pole).

2. "Forcing rebuild of all source files due to a change in the command line since the last build."
   To wydaje się być znanym błędem VS. ( https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in- wiersz poleceń od czasu ostatniej kompilacji ) i wydaje się, że został naprawiony w nowszych wersjach (ale nie VS2013). Nie znam żadnego obejścia, ale jeśli tak, to z pewnością opublikuj to tutaj.

Nie wiem, czy ktoś ma ten sam problem, ale właściwości mojego projektu "Configuration Properties" -> C/C++ -> "Debug Information Format"ustawiono na „Brak”, a kiedy przestawiłem go z powrotem na domyślną „Baza danych programu (/ Zi)”, co powstrzymywało kompilację projektu za każdym razem .

Kolejne proste rozwiązanie, do którego odwołuje się Visual Studio Forum .

Zmiana konfiguracji: menu Narzędzia → Opcje → Projekty i rozwiązania → Ustawienia projektu VC ++ → Tryb Eksploratora rozwiązań, aby wyświetlić wszystkie pliki .

Następnie możesz zobaczyć wszystkie pliki w Eksploratorze rozwiązań.

Znajdź pliki oznaczone żółtą ikoną i usuń je z projektu.

W porządku.

Visual Studio 2013 - „Wymuszanie ponownej kompilacji wszystkich plików źródłowych z powodu braku PDB”. Włączyłem szczegółowe wyniki kompilacji, aby zlokalizować problem: Włączyłem opcję „Szczegółowe” kompilacje w menu „Narzędzia” → „Projekty i rozwiązania” → „Kompiluj i uruchamiaj”.

Miałem kilka projektów, wszystkie C ++, ustawiłem opcję dla ustawień projektu: (C / C ++ → Format informacji debugowania) do Bazy danych programu (/ Zi) dla projektu powodującego problem. Nie zatrzymało to jednak problemu tego projektu. Problem pochodził z jednego z innych projektów C ++ w rozwiązaniu.

Ustawiam wszystkie projekty C ++ na „Baza danych programu (/ Zi)”. To rozwiązało problem.

Ponownie projekt zgłaszający problem nie był projektem problemowym. Spróbuj ustawić wszystkie projekty na „Baza danych programu (/ Zi)”, aby rozwiązać problem.

Dzisiaj spotkałem ten problem, ale był nieco inny. Miałem projekt CUDA DLL w moim rozwiązaniu. Kompilacja w czystym rozwiązaniu była prawidłowa, ale w przeciwnym razie nie powiodła się, a kompilator zawsze traktował projekt CUDA DLL jako nieaktualny.

Wypróbowałem rozwiązanie z tego postu .

Ale w moim rozwiązaniu nie brakuje pliku nagłówka. Potem znalazłem przyczynę w moim przypadku.

Wcześniej zmieniłem katalog pośredni projektu, chociaż nie spowodowało to problemów. A teraz, kiedy zmieniłem katalog pośredni projektu CUDA DLL Project z powrotem na $ (Konfiguracja) \, wszystko znów działa poprawnie.

Wydaje mi się, że istnieje niewielki problem między dostosowaniem kompilacji CUDA a niestandardowym katalogiem pośrednim.

Miałem podobny problem i wykonałem powyższe instrukcje (zaakceptowaną odpowiedź), aby zlokalizować brakujące pliki, ale nie bez podrapania się po głowie. Oto moje streszczenie tego, co zrobiłem. Aby być dokładnym, nie brakuje plików, ponieważ projekt nie wymaga ich budowy (przynajmniej w moim przypadku), ale są to odniesienia do plików, które nie istnieją na dysku, które nie są tak naprawdę wymagane.

Oto moja historia:

1. W systemie Windows 7 plik znajduje się pod adresem %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%. Istnieją dwa podobne pliki devenv.exe.config.configi devenv.exe.config. Chcesz zmienić później.

2. W systemie Windows 7 nie masz uprawnień do edytowania tego pliku znajdującego się w plikach programu. Po prostu skopiuj go gdzieś indziej (na pulpicie) zmień go, a następnie skopiuj z powrotem do lokalizacji plików programu.

3. Próbowałem dowiedzieć się, jak podłączyć DebugView do IDE, aby zobaczyć brakujące pliki. Cóż, nie musisz nic robić. Po prostu uruchom go, a przechwyci wszystkie wiadomości. Upewnij się, że w Capture Eventsmenu wybrano opcję Capturemenu, która domyślnie powinna zostać wybrana.

4. DebugView NIE wyświetli wszystkich brakujących plików naraz (przynajmniej nie dla mnie)! Powinieneś uruchomić DebugView, a następnie uruchomić projekt w Visual Studio 2010. Zostanie wyświetlony monit project out of date, wybierz Tak, aby skompilować, a DebugView wyświetli pierwszy brakujący plik lub powodujący przebudowę. Otwórz plik projektu (nie plik rozwiązania) w Notatniku, wyszukaj ten plik i usuń go. Lepiej zamknij projekt i ponownie go otwórz podczas usuwania. Powtarzaj ten proces, aż DebugView nie pokaże już brakujących plików.

5. Przydatne jest ustawienie filtra wiadomości na nieaktualny za pomocą przycisku paska narzędzi DebugView lub opcji Edytuj → Filtruj / Podświetl . W ten sposób wyświetlane są tylko te wiadomości, które zawierają ciąg „nieaktualny”.

Miałem wiele plików, które były niepotrzebnymi odniesieniami, a usunięcie ich wszystkich rozwiązało problem po wykonaniu powyższych kroków.

Drugi sposób na znalezienie wszystkich brakujących plików jednocześnie

Istnieje drugi sposób na znalezienie tych plików naraz, ale wiąże się to z (a) kontrolą źródła i (b) integracją go z Visual Studio 2010. Używając Visual Studio 2010 , dodaj swój projekt do pożądanej lokalizacji lub fikcyjnej lokalizacji w źródle kontrola. Spróbuje dodać wszystkie pliki, w tym również te, które nie istnieją na dysku, ale są wymienione w pliku projektu. Przejdź do oprogramowania do kontroli źródła, takiego jak Perforce , i powinno oznaczyć te pliki, które nie istnieją na dysku, w innym schemacie kolorów. Perforce pokazuje im czarny zamek. To są twoje brakujące referencje. Teraz masz ich listę i możesz usunąć je wszystkie z pliku projektu za pomocą Notatnika, a Twój projekt nie narzekałby na nieaktualne .

Dla mnie była to obecność nieistniejącego pliku nagłówka w „Plikach nagłówka” w projekcie. Po usunięciu tego wpisu (kliknij prawym przyciskiem myszy> Wyklucz z projektu) po raz pierwszy ponownie skompiluj, a następnie bezpośrednio

========== Kompilacja: 0 powiodło się, 0 nie powiodło się, 5 na bieżąco, 0 pominięto ==========

i nie podjęto żadnej próby odbudowy bez modyfikacji. Myślę, że jest to sprawdzanie przed kompilacją zaimplementowane przez VS2010 (nie jestem pewien, czy może to być udokumentowane), które wyzwala flagę „AlwaysCreate”.

Jeśli używasz wiersza polecenia MSBuild (nie Visual Studio IDE), na przykład jeśli celujesz w AppVeyor lub po prostu wolisz wiersz poleceń, możesz dodać tę opcję do wiersza polecenia MSBuild:

/fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8

Jak tu udokumentowano (ostrzeżenie: zwykła gadatliwość MSDN). Kiedy budowa się zakończy, szukać napisu will be compiledw pliku dziennika stworzonego podczas kompilacji, MyLog.log.

Korzystam z programu Visual Studio 2013 Professional z aktualizacją 4, ale nie znalazłem rozwiązania w przypadku żadnej z innych sugestii, jednak udało mi się rozwiązać problem z moim projektem zespołu.

Oto, co zrobiłem, aby spowodować problem -

• Utworzono nowy obiekt klasy (Projekt -> Dodaj klasę)
• Zmieniłem nazwę pliku za pomocą Eksploratora rozwiązań i kliknąłem „Tak”, gdy zostaniesz zapytany, czy chcę automatycznie zmienić nazwę wszystkich referencji, aby pasowały

Oto, co zrobiłem, aby rozwiązać problem -

• Idź do Team Explorer Home
• Kliknij Eksplorator kontroli źródła
• Przejdź do folderu, w którym znajdują się wszystkie pliki klas / projektów
• Znalazłem ORYGINALNĄ nazwę pliku na liście i usunąłem ją prawym przyciskiem myszy
• Budować

Jeśli tak jest w twoim przypadku, upewnij się, że usuwasz plik fantomu, a nie ten, który chcesz zachować w projekcie.

Miałem ten problem i znalazłem to:

http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html

Projekt Visual C ++ ciągle nieaktualny ( winwlm.h macwin32.h rpcerr.h macname1.hbrak)

Problem:

W Visual C ++ .Net 2003 jeden z moich projektów zawsze twierdził, że jest nieaktualny, mimo że nic się nie zmieniło i nie zgłoszono żadnych błędów w ostatniej wersji.

Otwarcie pliku BuildLog.htm dla odpowiedniego projektu pokazało listę błędów PRJ0041 dla tych plików, z których żaden nie pojawia się w moim systemie nigdzie: winwlm.h macwin32.h rpcerr.h macname1.h

Każdy błąd wygląda mniej więcej tak:

  MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'.  

Twój projekt może nadal się kompilować, ale może nadal być nieaktualny, dopóki ten plik nie zostanie znaleziony.

Rozwiązanie:

Uwzględnij afxres.hzamiast w resource.hpliku .rc projektu.

Plik .rc projektu zawierał „#include resource.h”. Ponieważ kompilator zasobów nie honoruje #ifdefbloków preprocesora , przebije się i spróbuje znaleźć dołączone pliki, które powinien ignorować. Windows.h zawiera wiele takich bloków. Dołączenie pliku afxres.h zamiast tego naprawiło ostrzeżenia PRJ0041 i wyeliminowało okno dialogowe błędu „Projekt jest nieaktualny”.

W moim przypadku jeden z projektów zawiera wiele plików IDL. Kompilator MIDL generuje plik danych DLL o nazwie „dlldata.c” dla każdego z nich, niezależnie od nazwy pliku IDL. Spowodowało to, że Visual Studio kompiluje pliki IDL na każdej kompilacji, nawet bez zmian w żadnym z plików IDL.

Obejściem tego problemu jest skonfigurowanie unikalnego pliku wyjściowego dla każdego pliku IDL (kompilator MIDL zawsze generuje taki plik, nawet jeśli przełącznik / dlldata zostanie pominięty):

• Kliknij plik IDL prawym przyciskiem myszy
• Wybierz Właściwości - MIDL - Wyjście
• Wprowadź unikalną nazwę pliku dla pliku DllData nieruchomości

Spędziłam wiele godzin na tym, by rozerwać mi włosy. Wyniki kompilacji nie były spójne; różne projekty byłyby „nieaktualne” z różnych powodów, od jednej kompilacji do następnej kompilacji z rzędu. W końcu odkryłem, że winowajcą był DropBox (3.0.4). Łączę folder źródłowy z ... \ DropBox do folderu projektów (nie jestem pewien, czy to jest powód), ale DropBox jakoś „dotyka” plików podczas kompilacji. Wstrzymano synchronizację i wszystko jest stale aktualne.

Istnieje kilka potencjalnych przyczyn i - jak wspomniano - musisz je najpierw zdiagnozować, ustawiając dla MSBuild szczegółowość na „Diagnostyka”. Przez większość czasu podany powód byłby oczywisty i można by na nim natychmiast zareagować, ALE czasami MSBuild błędnie twierdzi, że niektóre pliki są modyfikowane i należy je skopiować.

W takim przypadku należy wyłączyć tunelowanie NTFS lub zduplikować folder wyjściowy do nowej lokalizacji. Oto więcej słów.

Zdarzyło mi się to wiele razy, a potem odeszło, zanim mogłem zrozumieć, dlaczego. W moim przypadku było to:

Zły czas systemowy w konfiguracji podwójnego rozruchu!

Okazuje się, że mój podwójny rozruch z Ubuntu był główną przyczyną !! Byłem zbyt leniwy, aby naprawić Ubuntu, aby przestać zadzierać z moim zegarem sprzętowym. Kiedy loguję się do Ubuntu, czas przeskakuje o 5 godzin do przodu.

Pech, raz zbudowałem projekt z niewłaściwym czasem systemowym, a potem go skorygowałem. W rezultacie wszystkie pliki kompilacji miały błędne znaczniki czasu, a VS pomyślałby, że wszystkie są nieaktualne i odbudowałby projekt.

Większość systemów kompilacji korzysta ze znaczników czasu danych, aby określić, kiedy powinny nastąpić przebudowy - znacznik daty / czasu dowolnego pliku wyjściowego jest sprawdzany względem czasu ostatniej modyfikacji zależności - jeśli którakolwiek z zależności jest świeższa, wówczas cel jest odbudowywany.

Może to powodować problemy, jeśli którakolwiek z zależności w jakiś sposób otrzyma niepoprawny znacznik czasu danych, ponieważ trudno jest, aby znacznik czasu dowolnego wyniku kompilacji kiedykolwiek przekroczył znacznik czasu pliku, który rzekomo utworzono w przyszłości: P

Dla mnie problem pojawił się w projekcie WPF, w którym niektóre pliki miały właściwość „Build Action” ustawioną na „Resource”, a ich „Copy to Output Directory” na „Copy if nower”. Wydaje się, że rozwiązaniem jest zmiana właściwości „Kopiuj do katalogu wyjściowego” na „Nie kopiuj”.

msbuild wie, że nie kopiuje plików „Resource” na dane wyjściowe - ale nadal uruchamia kompilację, jeśli ich nie ma. Może to można uznać za błąd?

Jest to niezwykle pomocne w udzielonych tutaj odpowiedziach wskazujących, jak zmusić msbuild do rozsypania fasoli, dlaczego wciąż buduje wszystko!

Jeśli zmienisz argumenty polecenia debugowania dla projektu, spowoduje to również wyświetlenie komunikatu o konieczności przebudowania projektu. Mimo że argumenty debugujące nie wpływają na sam cel, właściwości projektu uległy zmianie. Jeśli jednak przebudujesz, komunikat powinien zniknąć.

Miałem podobny problem z Visual Studio 2005, a moje rozwiązanie składało się z pięciu projektów w następującej zależności (najpierw zbudowanych u góry):

Video_Codec depends on nothing
Generic_Graphics depends on Video_Codec
SpecificAPI_Graphics depends on Generic_Graphics
Engine depends on Specific_Graphics
Application depends on Engine.

Odkryłem, że projekt Video_Codec chciał pełnej kompilacji nawet po pełnym wyczyszczeniu, a następnie przebudowaniu rozwiązania.

Naprawiłem to, upewniając się, że pdbplik wyjściowy C / C ++ i linkera odpowiada lokalizacji używanej przez inne działające projekty. Włączyłem także RTTI.

Kolejny w Visual Studio 2015 SP3, ale kilka lat temu napotkałem podobny problem w Visual Studio 2013.

Mój problem polegał na tym, że w jakiś sposób wykorzystano niewłaściwy plik CPP dla prekompilowanych nagłówków (więc miałem dwa pliki CPP, które utworzyły prekompilowane nagłówki). Teraz, dlaczego Visual Studio zmieniło flagi na niewłaściwym cpp na „tworzenie prekompilowanych nagłówków” bez mojej prośby, nie mam pojęcia, ale tak się stało ... może jakiś plugin czy coś ???

W każdym razie niewłaściwy plik CPP zawiera plik version.h, który jest zmieniany w każdej kompilacji. Tak więc Visual Studio odbudowuje wszystkie nagłówki i dlatego cały projekt.

Cóż, teraz wróciło do normalnego zachowania.

Miałem projekt VC ++, który zawsze kompilował wszystkie pliki i był wcześniej uaktualniany z VS2005 do VS2010 (przez innych ludzi). Odkryłem, że wszystkie pliki cpp w projekcie oprócz StdAfx.cpp zostały ustawione na Utwórz (/ Yc) prekompilowany nagłówek. Zmieniłem to tak, że tylko StdAfx.cpp zostało ustawione do utworzenia prekompilowanego nagłówka, a pozostałe zostały ustawione na Użyj (/ Yu) prekompilowanego nagłówka i to naprawiło problem dla mnie.

Korzystam z programu Visual Studio 2013 i właśnie zaktualizowałem aktualizację do systemu Windows 10 maja 2019 r. I kompilacja musiała być za każdym razem powtarzana ponownie, niezależnie od zmian. Próbowałem zmienić nazwę pch na ProjectName zamiast TargetName, szukałem brakujących plików ze szczegółowym dziennikiem i tym skryptem Python, ale w końcu to mój czas nie był zsynchronizowany z serwerami MS (jak milisekundy).

To rozwiązało dla mnie to

• „Dostosuj datę i godzinę” w panelu sterowania
• "Synchronizuj teraz"

Teraz moje projekty nie wymagają ponownej kompilacji bez powodu.

Myślę, że umieściłeś jakiś znak nowej linii lub inną spację. Usuń go i ponownie naciśnij F5.

Projekty .NET są zawsze kompilowane niezależnie od tego. Częścią tego jest aktualizowanie IDE (np. IntelliSense). Pamiętam, jak zadałem to pytanie na forum Microsoftu lata temu i to była odpowiedź, którą otrzymałem.