[Feature Request]: Solution Filters for target frameworks as well as projects

[jamescrosswell]

Summary

Solution filters would allow us to configure

• subsets of projects to develop/build
• and subsets of frameworksto target for those builds

Background and Motivation

Currently we have multiple solution files in our repository. One of these exists mainly to enable us to set some flags in the Directory.Build.props, which get used later on to determine which frameworks to target.

Maintaining multiple solution files in a large project is a pain though. Ideally we'd have one solution file that contained all of the projects in the repository and we would have multiple solution filters.

Solution filters would allow us to configure

• subsets of projects to develop/build
• subsets of frameworksto target for those builds

So this is not a case of changing the build behaviour... it's just being able to filter the builds down to a more granular level than by project (we want to filter by target framework as well).

Proposed Feature

There are lots of possible designs. Picking the first one that comes to mind (not always the best):

• *.slnf files could have a <TargetFrameworksFilter> property
• build files (like *.csproj) could use that to filter the frameworks they target

For example, imagine a solution filter My.slnf:

{
  "targetFrameworksFilter": "net6.0;net5.0",
  "solution": {
    "path": "My.sln",
    "projects": [
      "My.csproj",
    ]
  }
}

And the following snippet in the My.csproj:

<TargetFrameworks Filter="TargetFrameworksFilter">net6.0;net5.0;netcoreapp3.0;netstandard2.1;netstandard2.0;net461</TargetFrameworks>

When buliding My.csproj ordinarily, builds would be created for all 6 of the target frameworks. However when building My.slnf, builds would only be created for net6.0 and net5.0.

Alternative Designs

Currently you can add conditions based on the solution name like:

<PropertyGroup Condition="'$(SolutionName)' != 'MySolution'">

If it was possible to add conditions based on the solution filter name as well, then that would also provide a way of changing target frameworks based on the solution filter being applied:

<TargetFrameworks Condition="$(SolutionFilterName)' != 'MyFilter'">$(TargetFrameworks);net6.0-android</TargetFrameworks>

That would be a more flexible solution, but then it might also give you enough rope to hang yourself.

[Nirmal4G]

What we need is a concept of Build Profiles for solutions and Target Profiles for projects. This should solve the problem of custom builds. 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.

[Nirmal4G]

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.

[jrdodds]

There's an issue open, requesting to modernize the solution file.

@Nirmal4G Is that open issue in a public place where comments and votes can be added in support of the request?

[Nirmal4G]

@jrdodds

I was commenting from mobile and was too lazy to search for the issue number.

To answer your Q—YES, the issue is public, been there for 7 years and here it is: #1730

[rainersigwald]

Please file desired features for .slnf as Visual Studio feedback--it is a Visual Studio feature that MSBuild mimics, not something MSBuild should extend.

[jamescrosswell]

I'm using solution filters with Jetbrains Rider myself... And on our CI servers we're running builds against solution filters just using dotnet build. So I'm not sure how the visual studio team could implement this. It needs support in msbuild right?

[rainersigwald]

Like the .sln format, the .slnf format is defined and controlled by Visual Studio, and some features of it are supported in MSBuild. If you talk the VS folks into adding this feature MSBuild could potentially be extended to support it. But extending MSBuild to support it without VS support doesn't make sense--the dependency and direction should go the other way.

[jamescrosswell]

Understood, thanks @rainersigwald !