SolutionFilterName does not work in the IDE

[mattleibow]

Steps to Reproduce

I have created a solution filter, but the IDE does not set the SolutionFilterName variable. This value is available since I see it in the solution explorer.

Based in this issue #6162

Expected Behavior

The SolutionFilterName variable is set to the name of the filter file.

Actual Behavior

The SolutionFilterName variable is not set at all.

Analysis

Versions & Configurations

Windows, VS 2019 16.10 P1 but I also saw this with P2

Attach a binlog

[danmoseley]

Hello @mattleibow thanks for the report. This seems like something that should go to the Visual Studio team. This repo is for the .NET platform. Please click the feedback button in VS and report it there.

[danmoseley]

Oh! Please disregard. I thought I was in the dotnet/runtime repo ☹️

[mattleibow]

Maybe related, I notice that from the CLI the variable is not there as part of the restore step: msbuild.zip

I have some conditions based on the filter to select some TFMs. As a result the restore calculates the TFMs without the filter, and then builds with the filter.

[benvillalobos]

Team Triage: Is the variable set via CLI outside of the restore step? Does this happen on a standard msbuild <yourproject> CLI build?

[Forgind]

This makes sense, since SolutionFile is where _solutionFilterFile is set, and that only happens when building a solution filter file from the command line. I'm assuming the binlog you sent was after opening a slnf in VS? If so, it seems that it's (correctly) identifying the solution file when parsing SolutionFileName, but I think the correct fix is also passing (and then setting) SolutionFilterFileName at the VS layer. I have a few guesses within the VS repo if you want to sync off GitHub, but I'm not very confident.

Also, I don't think it's Project System that sets it, but can you verify that @jjmew?

[Forgind]

Team triage: We decided this feature should not exist because we don't want build behavior to change based on a solution filter. Solution filters should reduce the amount of work a build does, but it should be a strict subset of the work a build of the connected solution file does. Closing as won't-fix.

[mattleibow]

Right now this exists via a command line build. This makes it inconsistent.

One benefit of this feature is that I could have a few filters that focus on a subset. For example, I could have a big solution, but then have an iOS and a Windows filter. This way I can have a Windows filter that can run on windows and not try build an iOS app, and in the same way an iOS filter that excludes the Windows targets.

[Forgind]

We actually removed support for this for command line builds as well in #6363.

Note that support for solution filter files still exists, so you could build a solution filter file that refers to a few projects only relevant for iOS, for instance, and it would automatically include anything they directly depend on but not other projects. The difficulty is that although we want to support building a subset of a solution, we don't want to change how the projects that are built are built, which is something you could do with this extra property.

[dotMorten]

We decided this feature should not exist because we don't want build behavior to change based on a solution filter.

But I do. Scenario: 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.

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.

[rainersigwald]

But I do.

It is often very tempting! But it creates a lot of room for error. Here, I would worry about incremental build problems related to the switch between NuGet and project references that would be very difficult to track down. If this were the only possible way to use the information I might be tempted to think it wasn't terrible, but it's easy to create worse situations using the filter name, so I prefer to require manual opt-in (like you've built).

[PureWeen]

We actually removed support for this for command line builds as well in #6363.

Note that support for solution filter files still exists, so you could build a solution filter file that refers to a few projects only relevant for iOS, for instance, and it would automatically include anything they directly depend on but not other projects. The difficulty is that although we want to support building a subset of a solution, we don't want to change how the projects that are built are built, which is something you could do with this extra property.

This doesn't work as well as it relates to multi targeting. We could create a platform dependent permutation of every single project file we have but it'd be nice to be able to just key off of the opening slnf to modify the TFMs.

Currently the IDEs hit scenarios where they take a really long time to process a multi targeted sln so it'd be nice to be able to use the SLNF files to target a specific platform if that's the only platform you care about. For example it currently takes 30 minutes for intellisense to process the MAUI repository because of how long the design time builds take iterating through all the TFMs

Or maybe there's a different more integrated solution where you could somehow open the IDE and tell it to only care about X TFMs and then no-op the rest?

With the .NET MAUI repository we setup all our TFMS in a Directory.Build.Props here
https://github.com/dotnet/maui/blob/main/Directory.Build.props#L68-L82

So, it'd be pretty easy for us to modify the TFMs given the right information

[dotMorten]

👆would love to be able to simply focus on one platform this way

[Nirmal4G]

What we need is a concept of Build Profiles or Target Profiles for both solutions and projects respectively. But first we need to have a MSBuild native solution file format. Solution files are a concept tied to VS IDE only right now!