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

W Visual Studio 2012 udało mi się osiągnąć ten sam wynik łatwiej niż w przyjętym rozwiązaniu.

Zmieniłem opcję w menu Narzędzia → opcje → projekty i rozwiązania → Build and Run → *MSBuild project build output verbosity " from Minimalto Diagnostic.

Następnie w wyjściu build znalazłem te same linie, szukając "nieaktualne":

Projekt 'blabla' nie jest aktualny. Pozycja projektu 'c:\foo\bar.XML 'posiada atrybut' Copy to Output Directory 'ustawiony na ' Copy always'.

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

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

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

Problem był jak stwierdzono powyżej " plik już nie istnieje na dysku."

To nie jest do końca poprawne. Plik istnieje na dysku, alePlik VCPROJ odwołuje się do pliku gdzie indziej.

Możesz to 'odkryć', przechodząc do "widoku plików dołączonych" i klikając po kolei każdy plik dołączony, aż znajdziesz ten, którego Visual Studio nie może znaleźć. Następnie dodajesz ten plik (jako istniejący element) i usuń odniesienie, którego nie można znaleźć i wszystko jest OK.

Ważne pytanie brzmi: jak Visual Studio może budować, jeśli nie wie, gdzie są pliki nagłówkowe?

Myślimy, żeplik vcproj ma jakąś względną ścieżkę do pliku obrażającego gdzieś, że nie pokazuje się w GUI Visual Studio, a to wyjaśnia, dlaczego projekt będzie rzeczywiście budować, mimo że widok drzewa Zawiera jest nieprawidłowy.

Zaakceptowana odpowiedź pomogła mi znaleźć właściwą drogę do rozwiązania tego problemu w przykręconym projekcie, z którym musiałem zacząć pracować. Jednak miałem do czynienia z bardzo dużą liczbą złych nagłówków. Z wyjściem verbose debug, usunięcie jednego spowodowało zamrożenie IDE na 30 sekund podczas wyprowadzania debug spew, co sprawiło, że proces przebiegał bardzo powoli.

Zniecierpliwiłem się i napisałem szybki i brudny skrypt Pythona, aby sprawdzić pliki projektu (Visual Studio 2010) pod kątem ja i wypisuję wszystkie brakujące pliki na raz, wraz z filtrami, w których się znajdują. Możesz znaleźć go jako Gist tutaj: https://gist.github.com/antiuniverse/3825678 (lub ten widelec obsługujący ś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.

Rzecz w tym, że każdy plik używany przez kompilator jest w *.plik tlog w katalogu tymczasowym. Po usunięciu pliku, to *.plik tlog nie jest aktualizowany. Jest to plik używany przez przyrostowe Kompilacje do sprawdzania, czy twój projekt jest aktualny.

Albo edytuj to .plik tlog ręcznie lub wyczyść projekt i Przebuduj.

Miałem podobny problem, ale w moim przypadku nie brakowało żadnych plików, wystąpił błąd w definiowaniu pliku wyjściowego pdb: zapomniałem przyrostka .pdb (dowiedziałem się z debug logging trick).

Aby rozwiązać problem 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ć dwa powody, z których oba można znaleźć, włączając "szczegółowe" wyjście budowania w "narzędzia"->"projekty i rozwiązania" - > "Buduj i uruchom".

1. "Forcing recompile of all source files due to missing PDB "..."
   Dzieje się tak, gdy wyłączasz wyjście informacji debugowania w opcjach kompilatora (w Ustawieniach projektu: "C/C++"->"debug Information Format" do "None" i "Linker"->"Generate debug Info" do "No": ). Jeśli zostawiłeś "C / C++" -> "nazwa pliku bazy danych programu" w domyślną (która jest " $(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ć znany błąd VS też (https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in-the-command-line-since-the-last-build) i wydaje się być naprawiony w nowszych wersjach (ale nie VS2013). Nie wiedziałem o obejściu problemu, ale jeśli to zrobisz, proszę to opublikować tutaj.

Nie wiem, czy ktoś inny ma ten sam problem, ale właściwości mojego projektu miały "Configuration Properties" -> C/C++ -> "Debug Information Format" ustawione na "None" , a kiedy przełączyłem go z powrotem na domyślną" Program Database (/Zi)", to powstrzymywało projekt przed rekompilacją za każdym razem.

Kolejne proste rozwiązanie opisane przez Visual Studio Forum .

Zmiana konfiguracji: menu Narzędzia → opcje → projekty i rozwiązania → Ustawienia projektu VC++ → Solution Explorer Mode to Pokaż wszystkie pliki.

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

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

Jest OK.

Spotkałem się z tym problemem dzisiaj, jednak było trochę inaczej. Miałem projekt CUDA DLL w moim rozwiązaniu. Kompilowanie w czystym rozwiązaniu było OK, ale poza tym nie powiodło się i kompilator zawsze traktował projekt CUDA DLL jako Nieaktualny.

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

Ale w moim rozwiązaniu nie ma brakujących plików nagłówkowych. Potem odkryłem powód w moim przypadku.

Zmieniłem już Katalog pośredni projektu, choć nie powodował kłopoty. i teraz, kiedy zmieniłem pośredni Katalog projektu CUDA DLL z powrotem do $(Configuration)\, wszystko działa dobrze ponownie.

Myślę, że jest jakiś mały problem między modyfikacją CUDA Build A nie domyślnym katalogiem pośrednim.

Miałem podobny problem i postępowałem zgodnie z powyższymi instrukcjami (zaakceptowaną odpowiedzią), aby zlokalizować brakujące pliki, ale nie bez drapania się po głowie. Oto moje podsumowanie tego, co zrobiłem. Aby być dokładnym, nie są to brakujące pliki, ponieważ nie są one wymagane przez projekt do budowania( przynajmniej w moim przypadku), ale są to odniesienia do plików, które nie istnieją na dysku, które tak naprawdę nie są wymagane.

Oto moja historia:

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

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

3. Próbowałem dowiedzieć się, jak połączyć DebugView Z IDE, aby zobaczyć brakujące pliki. Nie musisz nic robić. Po prostu go Uruchom, a przechwyci wszystkie wiadomości. Upewnij się Capture Events opcja menu jest zaznaczona w menu Capture, które domyślnie powinno być zaznaczone.

4. DebugView nie wyświetli wszystkich brakujących plików na raz(przynajmniej nie dla mnie)! Będziesz miał uruchomiony DebugView, a następnie uruchom projekt w Visual Studio 2010. Wyświetli komunikat project out of date, Wybierz Yes aby zbudować i DebugView pokaże pierwszy plik, którego brakuje lub który powoduje odbudowę. Otwórz plik projektu (nie Plik rozwiązania) w Notatniku i wyszukaj ten plik i usuń go. Lepiej zamknąć projekt i ponownie go otworzyć podczas usuwania. Powtórz ten proces, dopóki DebugView nie wyświetli brakujących plików.

5. Warto ustawić filtr wiadomości na Nieaktualny z przycisku na pasku narzędzi DebugView lub Edytuj → opcja Filter / Highlight . W ten sposób wyświetlane są tylko komunikaty, które zawierają ciąg "nieaktualne".

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

Drugi sposób, aby znaleźć wszystkie brakujące pliki na raz

Istnieje drugi sposób, aby znaleźć te pliki na raz, ale wymaga to (a) kontroli źródeł i (b) integracji z Visual Studio 2010. używając Visual Studio 2010 , dodaj swój projekt do żądanej lokalizacji lub fikcyjnej lokalizacji w kontroli źródła. Spróbuje dodać wszystkie pliki, w tym te, które nie istnieją na dysku, ale odwołują się w pliku projektu. Przejdź do oprogramowania do kontroli źródeł, takiego jak Perforce , i powinien zaznaczyć te pliki, które nie istnieją na dysku w innym schemacie kolorów. Perforce pokazuje je z czarnym zamkiem na nich. To twoje brakujące referencje. Teraz masz listę ich wszystkich i możesz usunąć je wszystkie z pliku projektu za pomocą Notatnika, a twój projekt nie będzie narzekał na to, że jest Nieaktualny .

Visual Studio 2013 -- "wymuszanie przekompilowania wszystkich plików źródłowych z powodu braku PDB". Włączyłem szczegółowe wyjście kompilacji, aby zlokalizować problem: włączyłem" szczegółowe "wyjście kompilacji w "narzędzia" → "projekty i rozwiązania" → "Buduj i uruchamiaj".

Miałem kilka projektów, wszystkie C++, ustawiłem opcję w ustawieniach projektu: (C/C++ → debug Information Format) do bazy danych programu (/Zi) dla projektu problemu. Nie powstrzymało to jednak problemu dla tego projektu. Problem wynikał z jednego z Pozostałe Projekty C++ w rozwiązaniu.

Ustawiłem Wszystkie projekty C++ na "Program Database (/Zi)". To rozwiązało problem.

Ponownie, projekt zgłaszający problem nie był projektem problemowym. Spróbuj ustawić wszystkie projekty na" Program Database (/Zi)", aby rozwiązać problem.

Dla mnie była to obecność nieistniejącego pliku nagłówkowego na" plikach nagłówkowych " wewnątrz projektu. Po usunięciu tego wpisu (kliknij prawym przyciskiem myszy > wyklucz z projektu) po raz pierwszy skompilowany, a następnie bezpośrednio

========== Build: 0 succeed, 0 failed, 5 up-to-date, 0 skip ==========

I nie podjęto próby przebudowy bez modyfikacji. Myślę, że jest check-before-build zaimplementowany przez VS2010 (Nie wiem, czy udokumentowany, może być), który uruchamia flagę "AlwaysCreate".

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

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

Zgodnie z dokumentacją tutaj (Ostrzeżenie: zwykła słowność MSDN). Po zakończeniu kompilacji wyszukaj ciąg will be compiled w pliku dziennika utworzonym podczas kompilacji, MyLog.log.

Używam Visual Studio 2013 Professional z aktualizacją 4, ale nie znalazłem rozdzielczości z żadną 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ę)
• zmieniono nazwę pliku za pomocą Eksploratora rozwiązań i kliknięto tak, gdy zapytano, czy chcę automatycznie zmienić nazwę wszystkich odwołań na dopasowanie

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

• przejdź do Team Explorer Home
• Kliknij Source Control Explorer
• wywierć do folderu, w którym znajdują się wszystkie pliki klasy/projektu
• znalazł oryginalną nazwę pliku na liście i usunął ją poprzez kliknięcie prawym przyciskiem myszy
• Zbuduj

Jeśli tak jest dla ciebie, po prostu upewnij się, że usuwasz plik phantom, 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

Visual C++ Project ciągle Nieaktualny (winwlm.h macwin32.h rpcerr.h macname1.h Brak)

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

Otwieranie BuildLog.plik htm dla odpowiedniego projektu pokazano listę błędów PRJ0041 dla tych plików, z których żaden nie pojawia się w moim systemie gdziekolwiek: winwlm.h macwin32h 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 być nadal budowany, ale może nadal być nieaktualny, dopóki ten plik nie zostanie znaleziony.

Rozwiązanie:

Dołącz afxres.h zamiast resource.h wewnątrz projektu .plik rc.

Projektu .plik rc zawierał " # include resource.h". Ponieważ kompilator zasobów nie honoruje bloków preprocesora #ifdef, będzie się przedzierał i próbował znaleźć pliki nagłówkowe, które powinien ignorować. Okna.h zawiera wiele takich bloków. W tym afxres.zamiast tego Naprawiono Ostrzeżenia PRJ0041 i wyeliminowano 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. To spowodowało, że Visual Studio skompilować pliki IDL na każdym kompilacji, nawet bez zmian do żadnego z plików IDL.

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

• Kliknij prawym przyciskiem myszy Plik IDL
• Select Properties-MIDL-Output
• wprowadź unikalną nazwę pliku dla właściwości DllData

Spędziłem wiele godzin rozdzierając włosy nad tym. Dane wyjściowe kompilacji nie były spójne; różne projekty byłyby "nieaktualne"z różnych powodów od jednej kompilacji do następnej kompilacji. W końcu odkryłem, że winowajcą był DropBox (3.0.4). Łączę mój folder źródłowy z ...\DropBox do folderu Moje projekty( Nie wiem, czy to jest powód), ale DropBox jakoś "dotyka" plików podczas kompilacji. Wstrzymana synchronizacja i wszystko jest konsekwentnie up-to-date.

Istnieje kilka potencjalnych powodów i - jak zauważono - musisz najpierw je zdiagnozować, ustawiając MSBuild verbosity na "Diagnostic". W większości przypadków podany powód będzie oczywisty i będziesz mógł działać natychmiast, ale czasami MSBuild błędnie twierdzi, że niektóre pliki są modyfikowane i wymagają skopiowania.

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

Dla mnie problem pojawił się w projekcie WPF, w którym niektóre pliki miały właściwość 'Build Action' ustawioną na 'Resource' i 'Copy to Output Directory' ustawioną na 'Copy if newer'. Rozwiązaniem wydaje się zmiana właściwości 'Copy to Output Directory' na 'do not copy'.

Msbuild wie, że nie kopiuje plików 'Resource' na wyjście - ale nadal uruchamia kompilację, jeśli ich nie ma. Może to można uznać za pluskwę?

To jest bardzo pomocne z odpowiedzi tutaj podpowiadając, jak niech msbuild powie, dlaczego wszystko buduje!

Jeśli zmienisz argumenty polecenia debugowania dla projektu, spowoduje to również, że projekt musi zostać przebudowany wiadomość. Mimo że argumenty debugowania nie wpływają na sam cel, właściwości projektu uległy zmianie. Jeśli jednak odbudujesz, wiadomość powinna zniknąć.

Przytrafiło mi się to wiele razy, a potem odeszło, zanim odkryłam dlaczego. W moim przypadku było:

Zły czas systemowy w konfiguracji dual boot!

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

Ze względu na pecha, zbudowałem projekt raz, z niewłaściwym czasem systemowym, a następnie poprawiłem czas. W rezultacie, wszystkie pliki kompilacji miały złe znaczniki czasu, a VS pomyślałby, że wszystkie są nieaktualne i odbudowałby projekt.

Większość systemów budowania używa znaczników czasu do określenia, kiedy powinna nastąpić przebudowa-znacznik daty / czasu dowolnego pliku wyjściowego jest sprawdzany pod kątem czasu ostatniej modyfikacji zależności-jeśli któreś z zależności są świeższe, to cel jest odbudowywany.

Może to powodować problemy, jeśli któreś z Zależności w jakiś sposób uzyskają nieprawidłowy znacznik czasu danych, ponieważ trudno jest, aby znacznik czasu dowolnego wyjścia kompilacji kiedykolwiek przekroczył znacznik czasu pliku rzekomo utworzonego w przyszłości : P

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 (pierwszy zbudowany 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łnego zbudowania nawet po całkowitym oczyszczeniu, a następnie odbudowaniu rozwiązania.

Naprawiłem to, upewniając się, że plik wyjściowy pdb zarówno C/C++, jak i linker pasują do lokalizacji używanej przez inne działające projekty. Włączyłem też RTTI.

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

Mój problem polegał na tym, że w jakiś sposób niewłaściwy plik cpp został użyty do wstępnie skompilowanych nagłówków (więc miałem dwa pliki cpp, które utworzyły wstępnie skompilowane nagłówki). Dlaczego Visual Studio zmieniło flagi na niewłaściwym cpp na "create precompiled headers" bez mojej prośby nie mam pojęcia, ale tak się stało... może jakiś plugin czy coś???

Anyway, the wrong cpp file zawiera wersję.plik h, który jest zmieniany przy każdej kompilacji. Visual Studio przebudowuje więc wszystkie nagłówki i z tego powodu cały projekt.

Cóż, teraz wraca do normalnego zachowania.

Projekty. NET są zawsze rekompilowane niezależnie od tego. Częścią tego jest aktualizacja IDE (np. IntelliSense). Pamiętam, że zadawałem to pytanie na forum Microsoftu lata temu i taką odpowiedź otrzymałem.