Visual Studio는 수정되지 않은 프로젝트를 다시 빌드합니다.

Visual Studio는 수정되지 않은 프로젝트를 다시 빌드합니다.

---

따라서 제목에서 알 수 있듯이 현재 약 50 개의 프로젝트가 포함 된 VS2010 솔루션이 있습니다. 아무것도 참조하지 않는 "최상위"프로젝트를 변경해도 VS는 여전히 50 개의 프로젝트를 모두 다시 빌드합니다. 추가 기능없이 Visual Studio 2010 Ultimate를 실행하고 있습니다. ILMerge를 사용하여 모든 프로젝트를 단일 파일로 통합하고 있습니다.

하위 수준 dll의 타임 스탬프를 확인하여이를 확인했으며 코드가 건드리지 않았음에도 불구하고 실제로 다시 빌드되었음을 확인했습니다.

다음에 대한 모든 응답과 의견을 읽었습니다.

Visual Studio 2008은 계속 재 구축합니다.

Visual Studio는 모든 것을 계속 구축합니다.

내 솔루션에서 이상한 VS2010 빌드 결함이 발생합니다.

Visual Studio에서 C # 프로젝트를 다시 빌드해야하는 이유

그러나 대부분은 빌드 시간을 단축하기 위해 프로젝트 언로드에 대한 제안을 제공하지만 수정에 대해서는 구체적이지 않습니다. VS가 이러한 종속 프로젝트를 수정하지 않고 다시 빌드해야한다고 생각하는 이유를 알아 내려고합니다.

'도구> 옵션> 프로젝트 및 솔루션> 빌드 및 실행> 실행시 시작 프로젝트 및 종속성 만 빌드'를 켰지 만 효과는 없습니다.

또한 8 (간접) 종속성 만있는 "중간 수준"프로젝트를 다시 빌드하면 ILMerge가 호출되지 않고 종속 프로젝트가 수정되지 않은 경우에도 여전히 8 개 프로젝트를 모두 빌드합니다.

당신이 제공 할 수있는 통찰력에 대해 모든 사람에게 감사합니다.

추가됨

제안 사항 중 일부를 테스트하기 위해 새 WinForms 프로젝트를 처음부터 만들었습니다. 그런 다음 해당 솔루션 내에 두 개의 새 프로젝트를 만들었습니다. 두 개의 '최하위 수준'프로젝트에서 두 개의 새로운 프로젝트로 모든 코드와 리소스 (프로젝트 파일 아님)를 복사했습니다 (파일과 폴더를 Explorer의 파일과 폴더를 Visual Studio의 프로젝트에 놓음으로써 수행했습니다).

가장 낮은 프로젝트 인 B 는 다른 프로젝트를 참조하지 않았습니다. 다음 프로젝트 A 는 B 만 참조했습니다 . 따라서 필요한 .NET 및 외부 어셈블리 참조를 프로젝트에 추가하면 솔루션이 빌드됩니다.

그런 다음 새 WinForm 프로젝트 참조 A 를 가지고 전체 빌드를 수행했습니다. 따라서 참조 체인은 다음과 같습니다.

WinForm- > A- > B

그런 다음 WinForm 만 수정 하고 표준 빌드 (F6)를 수행했습니다. 이전과 마찬가지로 Visual Studio는 세 가지 프로젝트를 모두 다시 빌드했습니다.

프로젝트 B 에서 소스 파일을 체계적으로 정리 한 후 내 Resources.Designer.cs및 해당 리소스 Resources.resx의 .Properties.Resources개체를 사용하는 코드를 주석 처리하면 WinForm을 수정 하면 더 이상 전체 솔루션을 다시 빌드하지 않고 다시 빌드 할 수 있음을 발견했습니다. WinForm .

프로젝트 B에Resources.resx 및 Resources.Designer.cs다시 추가 (하지만 리소스를 사용하지 않도록 참조 된 코드를 주석 처리 한 상태로 두는 경우)는 전체 빌드 동작을 다시 도입합니다.

내 리소스 파일이 손상되었는지 확인하기 위해 다시 삭제 한 다음 새 파일을 만들고 (프로젝트 속성-> 리소스를 통해) 이전과 동일한 리소스 (단일 Excel 파일)를 다시 추가했습니다. 이 설정으로 전체 재 구축이 계속 발생합니다.

그런 다음 단일 리소스를 제거했지만 프로젝트 B에 리소스 파일을 남겼습니다 . 리소스가 추가되지 않았지만 리소스 파일이 여전히 프로젝트에있는 경우에도 전체 (불필요한) 다시 빌드가 발생합니다.

(.NET 3.5) 프로젝트에 리소스 파일을 추가하면 Visual Studio 2010이 항상 해당 프로젝트를 다시 빌드하는 것으로 보입니다. 버그 또는 의도 된 / 예상 된 동작입니까?

다시 한번 감사드립니다!

---

도구-옵션을 열고 프로젝트 및 솔루션-트리에서 빌드 및 실행을 선택한 다음 "MSBuild 프로젝트 빌드 출력 상세도"를 진단으로 설정합니다. 이것은 프로젝트를 구축하는 이유를 출력합니다.

'ReferencedProject'프로젝트가 최신 상태가 아닙니다. 프로젝트 항목 'c : \ some.xml'에는 '출력 디렉터리로 복사'속성이 '항상 복사'로 설정되어 있습니다.

또는

'MyProject'프로젝트가 최신 상태가 아닙니다. 입력 파일 'c : \ ReferencedProject.dll'은 출력 파일 'c : \ MyProject.pdb'이후에 수정됩니다.

이 경우 수정 사항은 최신 경우에만 some.xml을 복사하는 것입니다.

빌드 전후 이벤트도 빌드를 트리거 할 수 있습니다.

---

이것이 수정이라고 생각하지 않지만 내 상황에 맞는 해결 방법입니다.

원래는 Resources섹션 이 포함 된 50 개 중 약 5 개의 프로젝트가있었습니다 . 이러한 프로젝트는 항상 재건 될 것이며 따라서 그들이 의존하는 모든 것도 재건 될 것입니다. 그 5 개 프로젝트 중 하나는 다른 프로젝트 중 48 개가 참조한 "기본"레벨 라이브러리 였기 때문에 필요하지 않더라도 내 프로젝트의 96 %가 매번 다시 빌드됩니다.

내 해결 방법은 종속성 주입, 인터페이스 및 전용 "리소스"프로젝트를 사용하는 것이 었습니다. 이 5 개 프로젝트가 자체 Resources개체를 참조하도록하는 대신 원하는 리소스를 제공하는 각 프로젝트에 인터페이스를 만들었습니다. 그런 다음 이러한 리소스가 필요한 클래스는 생성자 (생성자 주입)에서 생성하는 동안 인터페이스를 전달해야합니다.

그런 다음 평소와 같은 실제 리소스 섹션이있는 별도의 "리소스"프로젝트를 만들었습니다. 이 프로젝트에는 리소스 자체와 인터페이스를 통해 해당 리소스를 제공하는 데 필요한 각 인터페이스에 대한 클래스 만 포함되었습니다. 이 프로젝트는 리소스 종속성이있는 다른 모든 프로젝트를 참조하고 프로젝트에 필요한 인터페이스를 구현합니다.

마지막으로, 아무것도 참조하지 않는 (그리고 exe가 실제로 빌드되고 내 컴포지션 루트가있는) "Top Level"프로젝트에서 "Resources"프로젝트를 참조하고 DI를 연결 한 다음 떠났습니다.

즉, 매번 두 개의 프로젝트 ( "Resources"및 "Top Level") 만 다시 빌드되고 부분 빌드 (Shift-F6)를 수행하면 전혀 다시 빌드되지 않습니다.

다시 말하지만, 훌륭한 해결 방법은 아니지만 빌드에 3 분 정도 걸릴 때마다 48 개의 프로젝트가 빌드되므로 불필요한 재 빌드로 하루에 30 ~ 90 분을 잃었습니다. 리팩토링하는 데 시간이 좀 걸렸지 만 좋은 투자라고 생각합니다.

다음은 단순화 된 다이어그램입니다. 에서 종속성 것을 참고 Main.exe로 Proj1하고이 Proj2혼란을 줄이기 위해 표시되지 않습니다.

이 디자인을 사용하면 섹션 에 대한 종속성이 없기 때문에 전체 다시 빌드를 트리거 Proj1하거나 Proj2트리거하지 않고 빌드를 수행 할 수 있습니다 Resources. 구현 Main에 대해서만 알고 Resources있습니다.

---

이것은 프로젝트에 실제로 존재하지 않는 파일이있을 때 발생합니다.
프로젝트는 파일이 변경되었는지 여부를 확인할 수 없으므로 (파일이 없기 때문에) 다시 빌드됩니다.

Simply look at all the files in the project, and search for the one that doesn't have an expandable arrow near it.

---

I had the same issue in VS 2015.

What did the trick for me is:

1. One project was referencing itself copy in some other project bin (magic, yes). This kind of stuff could be found when switching to diagnostic build output (in build options) and then trying to build projects one by one from the top of projects hierarchy - if you see the project that rebuilds even if nothing has been changed then see it's references.
2. I've changed all "copy always" files in all projects to "copy if newer". Basically, in all .csproj files replace <CopyToOutputDirectory>Always</CopyToOutputDirectory> to <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
3. Then I've disabled NTFS tunneling as described in this article with this powershell script:

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

After that I needed on rebuild and it seems working for now.

---

In my case the culprit was "Copy Local" setting of a referenced dll set to true and "Copy to Output Directory" setting a file set to Copy always.

---

The MSBuild team is collecting documentation about investigating build incrementality issues here: https://github.com/Microsoft/MSBuild/wiki/Rebuilding%20when%20nothing%20changed

---

I've finally found one more culprit that I had hard time finding by increasing the build log verbosity.

In some cases, MSBuild looks for vc120.pdb in the output folder, and if this file doesn't exist, it will rebuild the entire project. This occurs even if you have disabled debug symbol generation.

The workaround here is to enable debug symbols and let this file get generated, then disable the setting again without deleting the PDB file.

---

I had this same problem and it turned out to be related to a couple of project that had a copy local reference to a dll in their own output directory.

The key to finding this was having diagnostic output set for the build output, but also knowing what to look for in the log. Searching for: 'not up to date' was the key.

---

Here is an answer from VS2010 always rebuilds solution?

This issue is solved by changing the project files, cleaning solution, deleting all bin folders by hand, restarting Visual studio and rebuilding everything.

---

Based on your observations, it sounds like you have projects expressing dependencies to other projects in a way that isn't obvious. It is possible for orphaned dependencies to remain in project files without being apparent in the UI. Have you looked through a misbehaving project file after opening it in a text editor? Checked solution build dependencies?

If you're not able to spot anything, try recreating one of your projects from scratch to see if the new project exhibits the same problem. If the clean project builds correctly, you'll know that you have unwanted dependencies expressed somewhere. As far as I know, these would have to be in the project file(s) or the solution file, unless you have makefiles or other unusual build steps.

---

I had the same issues with you. I found that it came from some deleted files. When I had removed the files from my project, the issues was gone. Regards.

---

For this category of build problems setting MSBuild output verbosity to 'diagnostic' is indeed a necessary first step. Most of the time the stated reason for the re-builds would be enough to act upon, BUT occasionally MSBuild would erroneously claim that some files are modified and need to be copied.

If that is the case, you'd need to either disable NTFS tunneling or duplicate your output folder to a new location. Here it is in more words.

---

Another problem that frequently happens is when some item in your solution has a modified stamp that is in the future. This can happen if you set your clock forward, and then set your clock to the correct time. I had this happen while installing Linux.

In this case you can recursively touch all the files using git bash (yes, in Windows):

find . -exec touch {} \;

---

I had the problem of Visual Studio rebuilding projects when upgrading from Visual Studio 2015 to 2017 and I add this answer for the benefit of those who might experience similar problems, as it does not seem to be documented anywhere.

In my case, the problem was that all projects in the solution had the same intermediate Output path (obj). The file GeneratedInternalTypeHelper.cs gets generated by all projects containing XAML. Up to Visual Studio 2015, the build process apparently did not check for the file date of this file and thus no problem with it occurred. With VS2017 the file date of this file is checked and because a later project in the build process will overwrite it (with the same content), the earlier project will re-build, re-triggering the later build, ad infinitum.

The solution in this case is to ensure that all projects have differing intermediate output directories, which will make the problem go away.

---

필자의 경우 (혼합 된 C #, C ++ / CLI 및 네이티브 C ++ 솔루션) 일부 C ++ 프로젝트는 아무것도 변경되지 않았어도 다시 연결되었습니다. 나는 무슨 일이 일어나고 있는지 알아 내려고 오랜 세월을 보냈다. 결국 "명령 줄"옵션에서 PDB 출력 경로 (옵션 / Fd)가 폴더 설정 $ (IntDir)을 처리 할 수 ​​없다는 사실을 알아 냈습니다. 나는 그것을 제거했습니다-빈 값은 기본값을 올바르게 수행합니다-내 문제는 사라졌습니다.

참고 URL : https://stackoverflow.com/questions/14916729/visual-studio-rebuilds-unmodified-projects