search

dotnet / wpf

WPF is a .NET Core UI framework for building Windows desktop applications.
MIT License
7.07k stars 1.17k forks source link

Build intermittently fails due to missing generated source files #1362

Open davkean opened 5 years ago

davkean commented 5 years ago

I happened to capture a failure under a build log.

Actual behavior:

CSC : error CS2001: Source file 'C:\project-system\artifacts\Debug\obj\Microsoft.VisualStudio.ProjectSystem.Managed.VS\ProjectSystem\VS\PropertyPages\GetProfileNameDialog.g.cs' could not be found. [C:\project-system\src\Microsoft.VisualStudio.ProjectSystem.Managed.VS\Microsoft.VisualStudio.ProjectSystem.Managed.VS_doj0ahs0_wpftmp.csproj]
CSC : error CS2001: Source file 'C:\project-system\artifacts\Debug\obj\Microsoft.VisualStudio.ProjectSystem.Managed.VS\ ProjectSystem\VS\PropertyPages\DebugPageControl.g.cs' could not be found. [C:\project-system\src\Microsoft.VisualStudio .ProjectSystem.Managed.VS\Microsoft.VisualStudio.ProjectSystem.Managed.VS_doj0ahs0_wpftmp.csproj]

Expected behavior: No build failures.

Minimal repro: Build Log: Build.zip

davkean commented 5 years ago

tag @drewnoakes

vatsan-madhavan commented 5 years ago
davkean commented 5 years ago

These are command-line builds, I've seen them inside Visual Studio. They appear to be regressions as I've not seen them before and this code has not changed in a long time.

Unsure if we're hitting this in design-time builds, we populate the error list from both and haven't paid attention to where its coming from.

davkean commented 5 years ago

I forgot to mention, we're using .NET SDK + .NET Framework targets, so this may be a bad interaction there.

davkean commented 5 years ago

As a side note, the build log will tell what properties, etc are being set.

grubioe commented 5 years ago

@ryalanms can you investigate? Thanks

vatsan-madhavan commented 5 years ago

@ryalanms do we have updates on this?

/cc @dotnet/wpf-developers

ryalanms commented 5 years ago

@davkean, could you share a project that reproduces the problem? From what I understand, Visual Studio does not support multi-targeted projects. Are any single projects building for both .NET Core and .NET Framework? I haven't been able to reproduce the problem locally. Thanks.

davkean commented 5 years ago

@ryalanms None of these projects are multi-targeting, but VS does support multi-targeting projects. In fact the project that is hitting the bug adds said multi-targeting support to VS. :)

This is also outside of Visual Studio via the command-line.

The solution is http://github.com/dotnet/project-system, but its very very inconsistent. Does the build log not give insights into this?

davkean commented 5 years ago

I've looked at the build log and this is what I've found so far:

It looks like the target that generates them (MarkupCompilePass1) is correctly being invoked and the files are being (somehow) getting deleted by the time the temporary assembly is being generated (MarkupCompilePass2ForMainAssembly):

: image

Are you aware of any situations (other than clean) that these generate files get deleted? Maybe this was overlapping builds (maybe I had VS open and it kicked off a design-time build in response to something that deleted the files?)

ryalanms commented 5 years ago

Thanks, @davkean. Yes, the build log appears to be normal, other than the missing generated files.

As to cleaning up the generated files, GenerateTemporaryTargetAssembly does clean up the intermediate output directory after compiling, but only for files that include the project + random string prefix:

https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/PresentationBuildTasks/Microsoft/Build/Tasks/Windows/GenerateTemporaryTargetAssembly.cs#L167

There haven't been any failures while building both from the command line with VS open and from VS. Unfortunately this won't make 3.0, but I will continue investigating and try to understand what could have removed the generated files as a build was occurring. Thanks.

davkean commented 5 years ago

Okay, but those deletes are for the project files, right? Not the generated source files?

ryalanms commented 5 years ago

Yes, that's right. Those deletes should only remove generated project files. There doesn't appear to be any code that deletes the generated files.

davkean commented 5 years ago

They do get cleaned by a "clean" - but its very doubtful that we'll call these targets during a design-time build.

chipplyman commented 1 year ago

I reproed this issue with a procmon trace active, attached.

VS 2022 was running in the background while the solution was being built on the command line. You can indeed see here that various instances of msbuild are fighting over the file, sometimes deleting it out from under each other (Operation=SetDispositionInformationEx). I know that Msbuild pids 62288, 64916 were each one of VS's /nodeReuse worker processes. I believe that pid 76804 was also a /nodeReuse worker that exited by the time I wrote this comment, and that 80324 was the command line instantiation.

ProcmonTrace1362.zip