As far as I can tell, the IDE is mandating that every platform does something with every configuration. AnyCPU isn't special - it was defined for the base Release/Debug flavors, so the IDE is going to create one for ReleaseXPStatic/DebugXPStatic. Fortunately, AnyCPU is pointless here and can be removed. But the same logic ends up applying AMD64 and ARM64 to ReleaseXPStatic/DebugXPStatic too, which doesn't make any sense, and the IDE generated projection ends up mapping them back to Win32 anyway (whichever CPU you pick, you get x86.)
Unrelated except found as part of the investigation here, but store packaging is a bit of a mess. https://github.com/microsoft/winfile/blob/8eb198d7cb65a3389c73d6998b007207c4503dfc/Package/Package.wapproj#L45 has the effect of triggering a build from the top level solution using x86 rather than Win32, which fails. However the packager really wants this to be a CPU architecture, not a generic configuration. From creating a new dummy project in the IDE, it looks like the current default is to have a solution define x86 but projects define Win32 and the solution maps x86 to Win32. This seems gross, but it does work. Here the same hack is applied in reverse, to tell the store packaging logic that a Win32 platform is an x86 CPU architecture.
(I'm kind of curious how the store package is affecting everyone. It fails for me without supplying the cert or changing the .wapproj file, so by default builds of the entire solution fails. The IDE was interesting in that if store support is not installed, it just doesn't load that subproject, but it does prompt to install store support when the solution is opened.)
In this PR, the solution defines both Win32 and x86. Only x86 is really needed for the build to succeed; Win32 is there to ensure that the solution builds with the same parameters as the project files (sigh), and to ensure that there is no breaking change for anyone currently using Win32. (I'm not happy about this duplication.)
This is an update to address the comment in https://github.com/microsoft/winfile/pull/417#issuecomment-2002553557 .
As far as I can tell, the IDE is mandating that every platform does something with every configuration. AnyCPU isn't special - it was defined for the base Release/Debug flavors, so the IDE is going to create one for ReleaseXPStatic/DebugXPStatic. Fortunately, AnyCPU is pointless here and can be removed. But the same logic ends up applying AMD64 and ARM64 to ReleaseXPStatic/DebugXPStatic too, which doesn't make any sense, and the IDE generated projection ends up mapping them back to Win32 anyway (whichever CPU you pick, you get x86.)
Unrelated except found as part of the investigation here, but store packaging is a bit of a mess. https://github.com/microsoft/winfile/blob/8eb198d7cb65a3389c73d6998b007207c4503dfc/Package/Package.wapproj#L45 has the effect of triggering a build from the top level solution using
x86rather thanWin32, which fails. However the packager really wants this to be a CPU architecture, not a generic configuration. From creating a new dummy project in the IDE, it looks like the current default is to have a solution definex86but projects defineWin32and the solution mapsx86toWin32. This seems gross, but it does work. Here the same hack is applied in reverse, to tell the store packaging logic that aWin32platform is anx86CPU architecture.(I'm kind of curious how the store package is affecting everyone. It fails for me without supplying the cert or changing the
.wapprojfile, so by default builds of the entire solution fails. The IDE was interesting in that if store support is not installed, it just doesn't load that subproject, but it does prompt to install store support when the solution is opened.)In this PR, the solution defines both
Win32andx86. Onlyx86is really needed for the build to succeed;Win32is there to ensure that the solution builds with the same parameters as the project files (sigh), and to ensure that there is no breaking change for anyone currently usingWin32. (I'm not happy about this duplication.)