Solution filter name as MSBuild variable

[rcmdh]

We are starting to use new solution filters more, including in our build - they're great. We have some conditional elements in our project files dependent on which .sln is being built, can you add support for which .slnf is being built / processed? I had a look through available variables, but couldn't see any that looked like the current .slnf.

[Forgind]

Should be doable. There are only 11 lines with "SolutionName" in them, so probably just add SolutionFilterFileName under the relevant ones, and it'll show up as desired. Does that sound like the solution you want @rcmdh?

[rcmdh]

Sounds great!

[Forgind]

@rcmdh, We decided to back this out, unfortunately. See #6325 (comment)

[dotMorten]

@Forgind Could this be reconsidered? From the sound of it, sounds like it was backed out because you didn't have the user stories to support it. So I'll start:

We have a solution filter that only opens the unit test projects. When opening project using this filter, I want to create a switch that uses nuget package references instead of project references, so that I can properly run my unit test with generated nuget packages, and also validate that these work correctly. The unit test projects won't even build when referencing the unloaded/filtered projects anyway, so naturally we do want to switch over.

For example

<ItemGroup Condition="'$(SolutionFilterName)'=='MySolutionFilter'">
    <PackageReference Include="MyProject" Version="*" />
</ItemGroup>
<ItemGroup Condition="'$(SolutionFilterName)'!='MySolutionFilter'">
    <ProjectReference Include="..\MyProject\MyProject.csproj" />
</ItemGroup>

This makes it super easy for anyone to just open the test solution filter and run the unit tests with the latest build.

Currently we do this with a manually set switch, but would be much easier and less error-prone to tie it to the filter.

[dotMorten]

This ☝️ a million times

[jamescrosswell]

I figured since this issue is closed, I'd create a feature request instead:
Solution Filters for target frameworks as well as projects #9159

[Nirmal4G]

Based on the comments, what we need is a concept of Build Profiles for solutions and Target Profiles for projects. But first we need to have a MSBuild native solution file format. Solution files are a concept tied to VS IDE only right now! They are verbose and not human friendly. There's an issue open, requesting to modernize the solution file.

Then again, SolutionFilterName provides an interim relief for those who doesn't want/like to maintain multiple solutions. I know that is a nightmare. Sure, tools like SlnGen makes it easy but still not source control friendly.

[CoenraadS]

Based on the comments, what we need is a concept of Build Profiles for solutions and Target Profiles for projects. But first we need to have a MSBuild native solution file format. Solution files are a concept tied to VS IDE only right now! They are verbose and not human friendly. There's an issue open, requesting to modernize the solution file.

Then again, SolutionFilterName provides an interim relief for those who doesn't want/like to maintain multiple solutions. I know that is a nightmare. Sure, tools like SlnGen makes it easy but still not source control friendly.

Is there an issue for Build/Target profiles?

My usecase is very similar to the situation described in: #6162 (comment)