Add support for $(SolutionConfiguration) and $(SolutionPlatform)

[danieldsmith]

Please consider adding support for $(SolutionConfiguration) and $(SolutionPlatform) macros.

We already have $(Configuration) and $(Platform) however these only represent the project configuration and platform respectively.

Having solution level macros would be super useful, as this would allow solutions with many projects to configure themselves depending on the overall solution configuration rather than having to define separate configurations for every solution/project combination.

Although I'm suggesting this be added to msbuild, just as a side note, there is a VS extension that attempts to add this missing functionality by injecting the solution macros during the build:
https://visualstudiogallery.msdn.microsoft.com/dc5d3209-d6a5-4675-a258-984577b5e979

However it would be much more convenient if these basic macros could be baked directly into msbuild, especially when it comes to headless build servers where installing plugins may not be an option.

Thanks,
Daniel

[dannyvv]

Hi Daniel,
Thanks for your suggestion. We recognize the elegance of the approach, but this doesn't meet the bar for our roadmap at this time.

The recommended way for people to obtain this behavior is to add an import to a shared props file that lives next to the solution.

<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory),Common.props))\Common.props" />

This approach also works for targets one might want to share and for people that use traversal projects rather than solutions.
People commonly add a folder to the solution and add the shared props files to that folder for convenient editing.

[SergiusTheBest]

It's pity that this feature is not implemented. I have different $(Configuration) in several projects and I want to put all output to bin\$(SolutionConfiguration)\$(SolutionPlatform). Currently this is not possible without hardcoding.

[zeromus]

Lame. This workaround is no substitute. Incorporate the extension, please.

[zezba9000]

Are there plans to add this? This idea is great!
csproj need better ways to work with native binaries in the post-build steps. Hope VS 2019 gets an update in this area.

[ceztko]

I'm the author of the extension "Solution Configuration Name". For several years, before release of VS2019, developing it as always been kind of a fun for me, as it was clear from the beginning that it was impossible to develop it cleanly without full access to VisualStudio source code. Especially having it supported in C++ projects became a nightmare and with VisualStudio 2019 I definitely stopped spending my time in trying to fix it. To my full admission, I never used the extension myself in any of my projects, but the more I get involved in cross platform projects, the more I would need it. Think about a solution that builds both C# and C++ projects: if you don't have $(SolutionPlatform) and just rely on $(Platform), by default 32 bit C# projects will go to a x86 folder, and 32 bit C++projects will go to a Win32 folder. Renaming platforms in either C# or C++ projects seems to be only partially supported and will fail with VisualStudio misbehaviors if you try to quickly do it for C# projects (I didn't invest too much time on this, though). Having a stock $(SolutionPlatform) would just be the right solution. I understood this is not so easy to have it working since it's not only about adding some kind of support of it in msbuild, but it's more about ensuring it will work language engines for C#, VC++, and so on. Again, in 2020 with all this need for crossplatform support I think it's the time to think more about it, or at least provide a truly fitting workaround, if possible.

@dannyvv : you suggested to add shared property file. How this is gonna help? The requirement here is to have two $(SolutionConfiguration), $(SolutionPlatform) that reflects the value of the checkboxes in the IDE.

[trueqbit]

Also, with ARM64EC and the availability of Windows 11 ARM64 this requirement is becoming even more prevalent.

I am just dealing with a real-life example where the C++ application executables are compiled native ARM64 (using the ARM64EC configuration), but for some reason a dependent DLL in the solution can only be built with the x64 configuration. This means that the x64 DLL ends up in a folder different from the .exe files, and it is just harder to configure and glue everything together.

[giladnoy]

We are also looking for a workaround for this issue for VS 2022.
We have multiple variations of apps in the same solution that we can switch between more easily by changing the solution configuration name, and since VS 2019 (and 2022) the extension we're using can no longer help us read the $(SolutionConfiguration) macro from the .csproj files.
We will be very grateful if you will consider adding the $(SolutionConfiguration) macro natively.