Incomplete prerequisites for compiling PowerToys

[lzandman]

Describe the requested doc changes

I think two essential things are missing from the "Prerequisites for Compiling PowerToys" section in DevDocs:

1. Not only enabling Windows Long Path support, but also enabling Git long paths support (i.e. git config --system core.longpaths true)
2. Powershell Core should be installed. I noticed the Visual Studio build process called pwsh ( I think here ).

[Muthusrihemadharshini]

"Hi! I've researched the missing prerequisites mentioned here. I have the specific Git command (git config --system core.longpaths true) and the PowerShell Core (pwsh) installation steps ready to add to the DevDocs. I'd love to submit a PR for this if you're ready for a contributor to take this on!"

[daverayment]

Hi @lzandman. I don't think shelling out to pwsh is required to build the solution, i.e. it's only for CI/CD tasks like package signing. Likewise, have you confirmed that git long paths is required? I'm able to build the solution without changing any git settings.

This has been confirmed by @Muthusrihemadharshini (see #44372 comments). If you're seeing errors when trying to build then it would be useful to see where our approaches differ.

[lzandman]

Hi @lzandman. I don't think shelling out to pwsh is required to build the solution, i.e. it's only for CI/CD tasks like package signing. Likewise, have you confirmed that git long paths is required? I'm able to build the solution without changing any git settings.

I was aware of @Muthusrihemadharshini attempt to fix this issue and you commenting that it might be a non-issue. I've done some experiments and I get the feeling you're right. Both Powershell and Git long paths aren't necessary. That said, I'm currently unable to build PowerToys. I've cloned a fresh new repository multiple times, both using Git long paths and without. Initialized the submodules and opened the slnx in the latest VS2022 update. However, I keep getting errors at the end of the build. Many messages of paths not found. I don't understand, as I was able to build PowerToys some weeks ago. Note that I'm building the ARM64 config.

So while I agree this issue may be moot, I'm currently unable to verify this.

[daverayment]

@snickler - are you still able to create ARM builds with VS2022? The OP has recently been experiencing path not found errors but has been able to build previously.

[snickler]

Yes, compiling with VS2022 still works with Arm64.

We need to see some of the build output logs to determine the issues faced.

[lzandman]

I did some more experimenting. It seems the first build fails with some missing WINMD files. When I restart a second build it succeeds. I've attached the output logs.

Output-Build-1.txt Output-Build-2.txt

[lzandman]

After investigation, it seems there are two separate but related causes, both related to build ordering rather than code correctness.

1. It looks like there's a race condition when doing the first (parallel) build. Project Microsoft.CommandPalette.Extensions.vcxproj does not compile, because of a race condition with its MIDL step. So no WINMD file is generated at the first build. I solved this by doing a manual MSBuild restore.

2. After I applied the fix of step 1, I got another error. Project LightSwitchService wasn't able to copy PowerToys.ManagedCommon.dll. I noticed LightSwitch didn't have a Build Dependency on ManagedCommon.

After I fixed these two things, it seems ARM64 builds from a fresh new clone succeed on my system.

In short:

1. Add a manual restore step to the DevDocs: msbuild PowerToys.slnx /t:Restore /p:Platform=ARM64 /p:Configuration=Debug

2. Add a Build Dependency to the LightSwitchService project, so it depends on the ManagedCommon project.

I can add a PR for this, but maybe it's good for you to first verify?

Update: What's weird is that LightSwitchService has a project-to-project reference dependency to ManagedCommon. So in theory this should result is a proper build order. However, I noticed the reference has a yellow triangle, which means there's something wrong with the reference. Maybe that's an issue that should be solved, instead of using a solution-level build order setting.

[daverayment]

@snickler Are you able to repro the ordering issues that @lzandman encountered with the ARM build? Or is this something you've tackled already with all your recent build improvements?

[snickler]

@snickler Are you able to repro the ordering issues that @lzandman encountered with the ARM build? Or is this something you've tackled already with all your recent build improvements?

I HAVE seen the ManagedCommon one before in the past after doing a second full rebuild after switching to a new branch and not cleaning any previously built bin/obj artifacts.

Luckily I happen to have 3 different Surface Laptop 7 devices I can test this out on to ensure whether it's still a thing, including one I haven't installed VS or any build tools on before.

[lzandman]

I’m going to close this issue, as the original problem I reported does not appear to apply after further investigation. While researching this issue, I did notice some other issues when trying to build PowerToys from a clean initial state. I've opened a separate issue to track these: #45281