Open davkean opened 5 years ago
tag @drewnoakes
BuildingInsideVisualStudio
? See WinFx.targetsThese 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.
I forgot to mention, we're using .NET SDK + .NET Framework targets, so this may be a bad interaction there.
As a side note, the build log will tell what properties, etc are being set.
@ryalanms can you investigate? Thanks
@ryalanms do we have updates on this?
/cc @dotnet/wpf-developers
@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.
@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?
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
):
:
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?)
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:
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.
Okay, but those deletes are for the project files, right? Not the generated source files?
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.
They do get cleaned by a "clean" - but its very doubtful that we'll call these targets during a design-time build.
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.
Windows version: 18362.239
Problem description: We've been intermittently hitting build failures in recent builds due to files usually generated by the XAML compiler missing. It will fail one time and immediately succeed next build and then won't fail against for a couple of hours. Multiple folks have started hitting it.
I happened to capture a failure under a build log.
Actual behavior:
Expected behavior: No build failures.
Minimal repro: Build Log: Build.zip