Visual Studio przebudowuje niezmodyfikowane projekty

Otwórz Narzędzia-Opcje, wybierz projekty i rozwiązania-Build i uruchom w drzewie, a następnie Ustaw "MSBuild project build output verbosity" na Diagnostic. To wyświetli powód budowy projektu, tzn.

Projekt "ReferencedProject" nie jest aktualny. Pozycja projektu "c:\some.XML 'posiada atrybut' Copy to Output Directory 'ustawiony na ' Copy always'.

Projekt 'MyProject' nie jest aktualny. Plik wejściowy "c:\ReferencedProject.dll ' jest modyfikowany po pliku wyjściowym 'c:\MyProject.pdb".

W tym przypadku poprawką jest skopiowanie niektórych.xml tylko wtedy, gdy jest nowszy.

Zdarzenia pre i post build mogą również wywołać build.

Dzieje się tak, gdy projekt ma plik, który tak naprawdę nie istnieje.
Projekt nie może określić, czy plik został zmieniony (ponieważ go tam nie ma), więc przebudowuje.

Wystarczy spojrzeć na wszystkie pliki w projekcie i wyszukać ten, który nie ma rozwijalnej strzałki w pobliżu.

Miałem ten sam problem w VS 2015.

Czym dla mnie jest sztuczka:

1. jeden projekt odnosił się do kopii w innym koszu projektu (magicznym, tak). Tego typu rzeczy można znaleźć podczas przełączania na diagnostyczne wyjście kompilacji (w opcjach kompilacji), a następnie próby budowania projektów jeden po drugim z góry hierarchii projektów - jeśli widzisz projekt, który przebudowuje, nawet jeśli nic nie zostało zmienione, zobacz jego referencje.
2. zmieniłem wszystkie pliki "Kopiuj zawsze" we wszystkich projektach "Kopiuj, jeśli nowsze". Zasadniczo, w sumie .pliki csproj zamieniają <CopyToOutputDirectory>Always</CopyToOutputDirectory> na <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
3. następnie wyłączyłem tunelowanie NTFS, jak opisano w Ten artykuł z tym skryptem powershell:

New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "MaximumTunnelEntries" -Value 0 -PropertyType "DWord"

Po tym potrzebowałem na odbudowę i wydaje się, że działa na razie.

W moim przypadku winowajcą było ustawienie "Copy Local" odwołanego zestawu dll na true I "Copy to Output Directory" ustawienie pliku ustawionego na kopiowanie zawsze.

W końcu znalazłem jeszcze jednego winowajcę, którego trudno było znaleźć, zwiększając szczegółowość dziennika budowy.

W niektórych przypadkach MSBuild szuka vc120.pdb w folderze wyjściowym, a jeśli ten plik nie istnieje, odbuduje cały projekt. Występuje to nawet jeśli wyłączyłeś generowanie symbolu debugowania .

Obejściem jest włączenie symboli debugowania i umożliwienie wygenerowania tego pliku, a następnie ponowne wyłączenie ustawienia Bez usuwania PDB plik.

Oto odpowiedź z VS2010 zawsze naprawia rozwiązanie?

Ten problem jest rozwiązany poprzez zmianę plików projektu, rozwiązanie czyszczenia, usuwanie wszystkich folderów bin ręcznie, ponowne uruchomienie programu Visual studio i odbudowuję wszystko.

Bazując na Twoich obserwacjach, wygląda na to, że masz projekty wyrażające zależności od innych projektów w sposób, który nie jest oczywisty. Osierocone zależności mogą pozostać w plikach projektu bez widoczności w interfejsie użytkownika. Czy przeglądałeś źle zachowujący się plik projektu po otwarciu go w edytorze tekstu? Sprawdzone zależności budowania rozwiązań?

Jeśli nie jesteś w stanie niczego zauważyć, spróbuj odtworzyć jeden ze swoich projektów od podstaw, aby zobaczyć, czy nowy projekt jest eksponowany ten sam problem. Jeśli czysty projekt zostanie poprawnie zbudowany, będziesz wiedział, że masz niechciane zależności wyrażone gdzieś. O ile wiem, musiałyby one znajdować się w pliku projektu lub pliku rozwiązania, chyba że masz pliki Makefile lub inne nietypowe kroki budowania.

Miałem te same problemy z Tobą. Odkryłem, że pochodzi z usuniętych plików. Kiedy usunąłem pliki z mojego projektu, problemy zniknęły. Pozdrawiam.

Dla tej kategorii problemów z kompilacją ustawienie wierności wyjściowej MSBuild na "diagnostyczną" jest rzeczywiście niezbędnym pierwszym krokiem. Przez większość czasu podany Powód ponownej kompilacji byłby wystarczający do działania, 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 więcej słów.

Innym problemem, który często się zdarza, jest sytuacja, gdy jakiś element w Twoim rozwiązaniu ma zmodyfikowany znaczek, który jest w przyszłości. Może się to zdarzyć, jeśli ustawisz zegar do przodu, a następnie Ustaw zegar na właściwą godzinę. Zdarzyło mi się to podczas instalacji Linuksa.

W tym przypadku możesz rekurencyjnie dotknąć wszystkich plików używając git bash (tak, w Windows):

find . -exec touch {} \;

Zespół MSBuild zbiera dokumentację dotyczącą badania problemów związanych z przyrostem kompilacji tutaj: https://github.com/Microsoft/MSBuild/wiki/Rebuilding%20when%20nothing%20changed

Miałem problem z projektami przebudowy Visual Studio podczas aktualizacji z Visual Studio 2015 Do 2017 i dodaję tę odpowiedź z korzyścią dla tych, którzy mogą doświadczyć podobnych problemów, ponieważ nie wydaje się być nigdzie udokumentowane.

W moim przypadku problem polegał na tym, że wszystkie projekty w rozwiązaniu miały tę samą pośrednią ścieżkę wyjściową (obj). Plik został wygenerowany w Internaltypehelper.cs jest generowany przez wszystkie projekty zawierające XAML. Do Visual Studio 2015, proces budowania najwyraźniej nie sprawdził daty Pliku tego pliku, a zatem nie wystąpił żaden problem z nim. W VS2017 sprawdzana jest data pliku tego pliku, a ponieważ późniejszy projekt w procesie budowania nadpisze go (z tą samą zawartością), wcześniejszy projekt ponownie zbuduje, ponownie wyzwalając późniejszą kompilację, ad infinitum.

Rozwiązaniem w tym przypadku jest upewnienie się, że wszystkie projekty mają różne pośrednie katalogi wyjściowe, co sprawi, że problem zniknie.

Miałem ten sam problem i okazało się, że jest związany z kilkoma projektami, które miały kopię lokalnego odniesienia do dll w ich własnym katalogu wyjściowym.

Kluczem do znalezienia tego było ustawienie wyjścia diagnostycznego dla wyjścia build, ale także wiedza, czego szukać w dzienniku. Szukanie: "nieaktualne " było kluczem.