Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

msbuild clean wrong files during compilation #11364

Open
payn-git opened this issue Jan 31, 2025 · 5 comments
Open

msbuild clean wrong files during compilation #11364

payn-git opened this issue Jan 31, 2025 · 5 comments
Assignees
Labels

Comments

@payn-git
Copy link

Issue Description

We have below structure in repository. When we are compiling individual folder solutions separately everything works correctly. We have also combined solution which contains all projects from all folders. If we will compile that solution everything works correctly. However, if we will compile combined solution first (compile correctly), and then we will compile just project2 (some code changes), msbuild will delete files which are part of the project1 from output directory even if project1 was not compiled at all. It seems that project2 FileListAbsolute.txt in obj compilation folder contain list of files from Project1 (probably generated when combined solution was compiled ?). As files which are not part of compiled solution are deleted from target location application will not start anymore. We have to go back and recompile Folder1 solution again. This is affecting productivity a lot and if people are not aware about this, they even spend lot of time investigating why those files are disappearing.

Please see attached binary log from compilation. Im not able to attach projects\solutions for reproducibility as those are protected IP.

Image

msbuild.DeletingWrongFiles.zip

MI.Biz.Plugin.Registration.csproj.FileListAbsolute.txt

Folder1

  • projects1
    • xml files in output dir
  • solution for Folder1

Folder2

  • projects2
    • dependency on project1
  • solution for Folder2

CombinedSolution (Folder1\Folder2)

Steps to Reproduce

Compile combined solution first. Compile individual projects afterwards.

Expected Behavior

Files which are not related\owned by compiled project\solution should not be deleted from compilation output directory.

Actual Behavior

Files which are not part of compiled project\solution are deleted from compilation output directory.

Analysis

No response

Versions & Configurations

MSBuild version 17.12.12+1cce77968 for .NET Framework
17.12.12.57101

@payn-git
Copy link
Author

Adding binary log for combined solution compilation which will lead to situation where Project2 FileListAbsolute.txt contains files which are not part of the project itself.

CombinedSolution.zip

@maridematte maridematte self-assigned this Feb 4, 2025
@payn-git
Copy link
Author

@maridematte Any update on this ? This issue affecting quite few developers in our company.

@crispim1411
Copy link

@payn-git, I attempted to replicate the bug following the described steps but couldn’t reproduce it. Is it still occurring on your side?

@payn-git
Copy link
Author

Yes its still happening and 100% reproducible. We are now on 17.13.19+0d9f5a35a for .NET Framework. Please see attached outputs from compilation. Performed actions:

  1. clone repository with source code (multiple root level folders where each contains solution for all projects inside folder)
  2. download all compile time dependencies for whole repo
  3. generate combined "monster solution" which combine all solutions from root folders to single solution
  4. compile generated monster solution
  5. Check output in one of the projects "obj" folder. *.csproj.FileListAbsolute.txt contains list of files which are not part of this project, they are part of the project which is configured as compile time dependency
  6. compile sub solution file from one of the root folders (one which contains project with *.csproj.FileListAbsolute.txt which is listing files which doesnt belong to given project)
  7. all files listed in *.csproj.FileListAbsolute.txt are deleted from target location even if they dont belong to compiled project...

I guess question is why is msbuild including files from referenced projects A inside *.csproj.FileListAbsolute.txt of project which has A configured as compile time dependency when generated monster solution is compiled. PS: exactly same is happening for each end every project. Mean if project have compile time dependency to A all files, all files from A are listed in *.csproj.FileListAbsolute.tx for such project. And when project is compiled individually all such files are deleted during compilation.

PS: for some reason I cant attach output form compilation. Upload will fail with no specific reason..... I can provide binlogs, generated monster solution and content of obj folder content from compilation on both monster solution and sub-solution....

@payn-git
Copy link
Author

payn-git commented Mar 24, 2025

And I just saw this :). It seems that's on purpose, but its not explaining why. And how to avoid that as this behavior is causing problems. Not sure in which scenario this is actually desired behavior.

https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-targets?view=vs-2022

GetCopyToOutputDirectoryItems
Get all project items that may need to be transferred to the output directory.
This includes baggage items from transitively referenced projects. It would appear
that this target computes full transitive closure of content items for all referenced
projects; however that is not the case. It only collects the content items from its
immediate children and not children of children.
The reason this happens is that
the ProjectReferenceWithConfiguration list that is consumed by _SplitProjectReferencesByFileExistence
is only populated in the current project and is empty in the children. The empty list
causes _MSBuildProjectReferenceExistent to be empty and terminates the recursion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants