Enable MultiProcessorCompilation

[Trenly]

• I have signed the Contributor License Agreement.
• I have updated the Release Notes.
• This pull request is related to an issue.

---

Microsoft Reviewers: Open in CodeFlow

[JohnMcPMS]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[florelis]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Trenly]

@florelis - Can I request a re-run? I'm not seeing what would have caused the PowerShell error

[JohnMcPMS]

@Trenly these seem to have started when we release 1.11.510 and are spurious. #5807 to start trying to get to the bottom of it.

[Trenly]

@JohnMcPMS - I noticed on Build #196599 there was an ENOSPC - Given that the test seemed to fail on installing PSTools, I'm curious if that step is also occasionally hitting ENOSPC thereby causing the install to fail and thus the test stage to fail, especially since ENOSPC doesn't affect all PRs

See also -

• https://dev.azure.com/shine-oss/winget-cli/_build/results?buildId=194765&view=results
• https://dev.azure.com/shine-oss/winget-cli/_build/results?buildId=191581&view=results

Edit: Created #5808 for tracking

[JohnMcPMS]

This happens so early in the job that I would be surprised if space were an issue. But regardless it would be good to add collecting the release winget logs in case they also have details on the reason for the error.

[JohnMcPMS]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Trenly]

That failure doesn't make sense to me. . .

I understand it's a linker error, but I don't see how that error would be appearing from this change - unless the dependencies aren't being built in the right order? But then why would it work locally and not here?

[JohnMcPMS]

That failure doesn't make sense to me. . .

I understand it's a linker error, but I don't see how that error would be appearing from this change - unless the dependencies aren't being built in the right order? But then why would it work locally and not here?

Were you clean building locally? I would expect that is the only way to test for sure.

This warning is suspicious, because all of the unresolved methods are in that file:

x64\Release\typeresolution.obj : warning LNK4042: object specified more than once; extras ignored

It makes me think that the multiprocessor build is processing this file twice and one of them is not so good.

[JohnMcPMS]

binlog for the (probable) reason, if not why it doesn't fail without:

typeresolution.h is being added to the ClCompile group because it is "Item Type" C/C++ compiler.

In External - Do Not Modify > UndockedRegFreeWinRT > Header Files > typeresolution.h > Properties > General > Item Type > should be C/C++ header.

[Trenly]

That failure doesn't make sense to me. . .
I understand it's a linker error, but I don't see how that error would be appearing from this change - unless the dependencies aren't being built in the right order? But then why would it work locally and not here?

Were you clean building locally? I would expect that is the only way to test for sure.

This warning is suspicious, because all of the unresolved methods are in that file:

x64\Release\typeresolution.obj : warning LNK4042: object specified more than once; extras ignored

It makes me think that the multiprocessor build is processing this file twice and one of them is not so good.

Yes, I made sure to clean the solution first.

[Trenly]

binlog for the (probable) reason, if not why it doesn't fail without:

typeresolution.h is being added to the ClCompile group because it is "Item Type" C/C++ compiler.

In External - Do Not Modify > UndockedRegFreeWinRT > Header Files > typeresolution.h > Properties > General > Item Type > should be C/C++ header.

I could add a condition to specifically exclude the UndockedRegFreeWinRT project, perhaps?

[JohnMcPMS]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Trenly]

/azp run

Thank you