[main] Update dependencies from dotnet/windowsdesktop

[dotnet-maestro]

This pull request updates the following dependencies

Coherency Updates

The following updates ensure that dependencies with a CoherentParentDependency
attribute were produced in a build used as input to the parent dependency's build.
See Dependency Description Format

• Coherency Updates:
  • Microsoft.NET.Sdk.WindowsDesktop: from 10.0.0-alpha.1.24563.1 to 10.0.0-alpha.1.24568.1 (parent: Microsoft.WindowsDesktop.App.Ref)
  • Microsoft.Dotnet.WinForms.ProjectTemplates: from 10.0.0-alpha.1.24560.1 to 10.0.0-alpha.1.24566.1 (parent: Microsoft.WindowsDesktop.App.Runtime.win-x64)
  • Microsoft.DotNet.Wpf.ProjectTemplates: from 10.0.0-alpha.1.24563.1 to 10.0.0-alpha.1.24568.1 (parent: Microsoft.WindowsDesktop.App.Runtime.win-x64)

From https://github.com/dotnet/windowsdesktop

• Subscription: 43b77b68-0b3c-49dd-3915-08d8e9750bf8
• Build: 20241118.1
• Date Produced: November 18, 2024 1:44:19 PM UTC
• Commit: fed5f2a4e66fe00be8d108e8e153ec3bed34941e
• Branch: refs/heads/main

• Updates:
  • Microsoft.WindowsDesktop.App.Ref: from 10.0.0-alpha.1.24563.2 to 10.0.0-alpha.1.24568.1
  • Microsoft.WindowsDesktop.App.Runtime.win-x64: from 10.0.0-alpha.1.24563.2 to 10.0.0-alpha.1.24568.1
  • VS.Redist.Common.WindowsDesktop.SharedFramework.x64.10.0: from 10.0.0-alpha.1.24563.2 to 10.0.0-alpha.1.24568.1
  • VS.Redist.Common.WindowsDesktop.TargetingPack.x64.10.0: from 10.0.0-alpha.1.24563.2 to 10.0.0-alpha.1.24568.1
  • Microsoft.NET.Sdk.WindowsDesktop: from 10.0.0-alpha.1.24563.1 to 10.0.0-alpha.1.24568.1
  • Microsoft.Dotnet.WinForms.ProjectTemplates: from 10.0.0-alpha.1.24560.1 to 10.0.0-alpha.1.24566.1
  • Microsoft.DotNet.Wpf.ProjectTemplates: from 10.0.0-alpha.1.24563.1 to 10.0.0-alpha.1.24568.1

[dotnet-maestro]

Notification for subscribed users from https://github.com/dotnet/windowsdesktop:

@dotnet/wpf-developers

Action requested: Please take a look at this failing automated dependency-flow pull request's checks; failures may be related to changes which originated in your repo.

• This pull request contains changes from your source repo (https://github.com/dotnet/windowsdesktop) and seems to have failed checks in this PR. Please take a peek at the failures and comment if they seem relevant to your changes.
• If you're being tagged in this comment it is due to an entry in the related Maestro Subscription of the Build Asset Registry. If you feel this entry has added your GitHub login or your GitHub team in error, please update the subscription to reflect this.
• For more details, please read the Arcade Darc documentation

[lonitra]

error:

repo-projects\Directory.Build.targets(635,5): error MSB3231: Unable to remove directory "D:\a\_work\1\vmr\src\wpf\artifacts\sb\". The process cannot access the file 'Windows.Win32.winmd' because it is being used by another process.

It seems the error that the directory is unable to be removed is happening consistently. @nagilson, @marcpopMSFT do you have any pointers on how this can be resolved or investigated further?

[ViktorHofer]

cc @JeremyKuhne - something is holding on Windows.Win32.winmd.

[JeremyKuhne]

Windows.Win32.winmd

Odd. I'll look.

[JeremyKuhne]

Source build is what is failing. It can't clean the packages folder in the artifacts directory after building WPF. I've built both WPF and WinForms locally and the only processes that are touching the file in question are VBCSCompiler.exe (WPF) and dotnet.exe (WinForms).

The targets explicitly shut down processes:

sdk/src/SourceBuild/content/repo-projects/Directory.Build.targets

Line 606 in 3ae5848

<Exec Command="$(DotnetTool) build-server shutdown --vbcscompiler"

And it is supposed to ignore deletion errors:

sdk/src/SourceBuild/content/repo-projects/Directory.Build.targets

Line 635 in 3ae5848

<RemoveDir Directories="@(DirsToDeleteWithTrailingSeparator)" ContinueOnError="true" />

Here is what I observed in procmon:

11:30:24.2704322 AM	VBCSCompiler.exe	36820	CreateFile	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: n/a, ShareMode: Read, AllocationSize: n/a, OpenResult: Opened
11:30:24.2760373 AM	VBCSCompiler.exe	36820	QueryStandardInformationFile	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	AllocationSize: 23,711,744, EndOfFile: 23,710,760, NumberOfLinks: 1, DeletePending: False, Directory: False
11:30:24.2760476 AM	VBCSCompiler.exe	36820	QueryStandardInformationFile	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	AllocationSize: 23,711,744, EndOfFile: 23,710,760, NumberOfLinks: 1, DeletePending: False, Directory: False
11:30:24.2760545 AM	VBCSCompiler.exe	36820	QueryStandardInformationFile	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	AllocationSize: 23,711,744, EndOfFile: 23,710,760, NumberOfLinks: 1, DeletePending: False, Directory: False
11:30:24.2760604 AM	VBCSCompiler.exe	36820	QueryStandardInformationFile	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	AllocationSize: 23,711,744, EndOfFile: 23,710,760, NumberOfLinks: 1, DeletePending: False, Directory: False
11:30:24.2760852 AM	VBCSCompiler.exe	36820	CreateFileMapping	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	FILE LOCKED WITH ONLY READERS	SyncType: SyncTypeCreateSection, PageProtection: PAGE_EXECUTE
11:30:24.2761185 AM	VBCSCompiler.exe	36820	QueryStandardInformationFile	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	AllocationSize: 23,711,744, EndOfFile: 23,710,760, NumberOfLinks: 1, DeletePending: False, Directory: False
11:30:24.2761388 AM	VBCSCompiler.exe	36820	CreateFileMapping	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	SyncType: SyncTypeOther
11:26:07.3206148 AM	dotnet.exe	27372	CreateFile	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: n/a, ShareMode: Read, AllocationSize: n/a, OpenResult: Opened
11:26:07.3207639 AM	dotnet.exe	27372	QueryEAFile	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	
11:26:07.3208736 AM	dotnet.exe	27372	QueryStandardInformationFile	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	AllocationSize: 23,711,744, EndOfFile: 23,710,760, NumberOfLinks: 1, DeletePending: False, Directory: False
11:26:07.3208888 AM	dotnet.exe	27372	CreateFileMapping	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	FILE LOCKED WITH ONLY READERS	SyncType: SyncTypeCreateSection, PageProtection: PAGE_EXECUTE
11:26:07.3209006 AM	dotnet.exe	27372	QueryStandardInformationFile	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	AllocationSize: 23,711,744, EndOfFile: 23,710,760, NumberOfLinks: 1, DeletePending: False, Directory: False
11:26:07.3209359 AM	dotnet.exe	27372	CreateFileMapping	C:\Users\{user}\.nuget\packages\microsoft.windows.sdk.win32metadata\60.0.34-preview\Windows.Win32.winmd	SUCCESS	SyncType: SyncTypeOther

We really need an SDK build and I don't know what we can do here. Presumably this wouldn't be happening if the source build was still disabled. #44937

Questions:

• Can we suppress this in some way with a follow up issue?
• Why isn't the package cache shared throughout the source build and cleaned up at the end? Does it even need cleaned up?

[JeremyKuhne]

@dotnet/product-construction can you help unblock here? I've detailed what I've seen above: #44922 (comment)

[ViktorHofer]

The targets explicitly shut down processes:

Does WPF use an OOB compiler? The shutdown command only works for the non OOB compiler that comes with the SDK.

And it is supposed to ignore deletion errors:

That unfortunately doesn't work as we also pass -warnAsError in which overrides that setting. Tried to fix this but needs more work: #44434

@JeremyKuhne this started happening with this dependency update so the diff should be dotnet/wpf@cbaeca8...d73dd1d

Can we suppress this in some way with a follow up issue?

Not that I know of, no.

Why isn't the package cache shared throughout the source build and cleaned up at the end? Does it even need cleaned up?

Because every repository needs to build in isolation for prebuilt detection. cc @dotnet/source-build

[JeremyKuhne]

@ViktorHofer

Does WPF use an OOB compiler? The shutdown command only works for the non OOB compiler that comes with the SDK.

Probably? How do I check?

this started happening with this dependency update so the diff should be dotnet/wpf@cbaeca8...d73dd1d

Yeah, WPF is now using the CsWin32 source generators as well (where the file in question transitively comes from). Nothing unusual outside of that.

[ViktorHofer]

Probably? How do I check?

A binlog should tell. Check the $csc task.

[JeremyKuhne]

A binlog should tell. Check the $csc task.

Yeah, WPF is: C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\Roslyn\csc.exe

Not sure where this comes from, will look later.

[JeremyKuhne]

@dotnet/product-construction stuck again.

The hack for the source generator depends on building with dotnet. WPF uses VS to build, and it isn't clear to me how to switch it to use dotnet. Need to make the C++ build cmake friendly, I guess? No idea where to begin on that. 🤷🏼‍♂️

Can we just force kill VBCSCompiler.exe when cleaning for now? Or is there some other temporary thing we can do to unblock?

[ViktorHofer]

Can we just force kill VBCSCompiler.exe when cleaning for now? Or is there some other temporary thing we can do to unblock?

Yes and no. We build other repositories which depend on desktop msbuild and the VS compiler in parallel (i.e. aspnetcore). dotnet build-server shutdown can handle termination but I'm not sure about the VBCSCompiler.

I think fixing #44434 so that lock errors are ignored when cleaning the repo's artifacts is the better option here.

[mmitche]

I poked around and it doesn't seem like VBCSCompiler has a similar graceful shutdown that works. There is a reference to one here: dotnet/roslyn#7930 but I haven't been able to get it to work. I don't think we can force kill it because it may not be as graceful as dotnet's build server. @jaredpar?

I think fixing #44434 so that lock errors are ignored when cleaning the repo's artifacts is the better option here.

Agreed. If that will take a long time, we maybe could skip cleaning WPF for now?

[jaredpar]

I poked around and it doesn't seem like VBCSCompiler has a similar graceful shutdown that works.

> vbcscompiler -shutdown

That will shut down all VBCSCompiler spawned from the same file system location using the default pipe name

I don't think we can force kill it because it may not be as graceful as dotnet's build server

The VBCSCompiler process is always safe to kill. It is an optimization. The entire build infra expects it to fail / crash / hang.

@jjonescz

[ViktorHofer]

Agreed. If that will take a long time, we maybe could skip cleaning WPF for now?

Let me try finishing #44434 tomorrow. I think that should be doable.

[jjonescz]

Does WPF use an OOB compiler? The shutdown command only works for the non OOB compiler that comes with the SDK.

I think you could also force the build to use the framework toolset compiler (by setting BuildWithNetFrameworkHostedCompiler=true) which is supported by the shutdown command (since #43135).

[ViktorHofer]

I think you could also force the build to use the framework toolset compiler (by setting BuildWithNetFrameworkHostedCompiler=true) which is supported by the shutdown command (since #43135).

Very useful, thanks for sharing. Two follow-up questions:

1. Does this also handle the .NETCoreApp compiler toolset package shutdown? I only see the netframework one in the code.
2. With the VMR we use the same SDK to build all repositories but each repository has its own isolated package cache. So the shutdown command wouldn't work here as the package cache env var would point to the global VMR's cache and not the individual repo's cache. Would it be possible to support a --packages argument in the build-server shutdown command so that we can point to a different location? The dotnet restore command has the same argument. If not, no worries. We can override the env var when we invoke the shutdown command.

[jjonescz]

1. Does this also handle the .NETCoreApp compiler toolset package shutdown? I only see the netframework one in the code.

No, that's not handled; I'm not sure it could be done easily (because it would use dotnet.exe not VBCSCompiler.exe). The framework one was added because it's used automatically in torn SDK situations (_IsDisjointMSBuildVersion).

2. Would it be possible to support a --packages argument in the build-server shutdown command so that we can point to a different location?

I guess that's possible, but overriding the env var seems simpler.

[jjonescz]

Hm, let's see if this works, I guess there was a reason this was disabled previously.

One reason might be that the toolset compiler was previously downloaded via PackageReference so it didn't work with CPM (but now it uses PackageDownload).

But also in wpf .net framework builds (which generate wpftmp projects), the toolset compiler doesn't work (PackageDownload is broken there). Not sure if that's relevant here.

[ViktorHofer]

I guess there was a reason this was disabled previously.

That was before we had the build-server shutdown support for the framework hosted compiler. CI green so thinks look good.

[am11]

Posted a related question dotnet/msbuild#11010. I'm guessing it is not by design and some sort of issue in msbuild->buildxl integration or issue in https://github.com/microsoft/BuildXL itself, but lets see.

Update: UseSharedCompilation=false in wpf.proj might be a better fix than BuildWithNetFrameworkHostedCompiler=true.