Unify .sln and Directory.Build.props into a single file

[alexandrehtrb]

Is your feature request related to a problem? Please describe.

Today, one has a .NET solution file (.sln) that references other project files (.csproj, .fsproj, .vbproj). The .sln file is in an unconventional format, differing from project files that follow a XML structure.

Also, to make solution-wide project configurations, the developer has to use Directory.Build.props files.

Describe the solution you'd like

I think .NET could have a new solution file format that 1) can be used for solution-wide configs and 2) is in a better structure format, like XML.

Additional context

Benefits

• One file instead of two files
• Better structure for parsing

[KieranFoot]

Are you suggesting doing away with Directory.Build.Props or just allowing similar syntax inside the .sln?

Personally, I use Directory.Build.Props at several layers of my projects and it's very useful as they work together to give the results I desire.

[alexandrehtrb]

I personally think it would be better to have just one .sln with configs, instead of many Directory.Build.props. We could have something like this in the solution file:

<Solution>

  <PropertyGroup>
    <!-- solution-wide properties -->
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <ProjectGroup Name="Source projects">

    <ProjectReference Include="./src/MyRunner/MyRunner.csproj"/>
    <ProjectReference Include="./src/MyDomain/MyDomain.csproj"/>
    <ProjectReference Include="./src/MyInfrastructure/MyInfrastructure.csproj"/>

  </ProjectGroup>

  <ProjectGroup Name="Test projects">

    <ProjectReference Include="./tests/MyUnitTests/MyUnitTests.csproj"/>
    <ProjectReference Include="./tests/MyIntegrationTests/MyIntegrationTests.csproj"/>

    <PackagesToInclude>
      <!-- these packages will be included in every project of this project group; no need to include in each project file -->
      <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0"/>
      <PackageReference Include="xunit" Version="2.6.3"/>
      <PackageReference Include="xunit.runner.visualstudio" Version="2.5.5">
        <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
        <PrivateAssets>all</PrivateAssets>
      </PackageReference>
      <PackageReference Include="coverlet.collector" Version="6.0.0">
        <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
        <PrivateAssets>all</PrivateAssets>
      </PackageReference>
    </PackagesToInclude>

  </ProjectGroup>

</Solution>

This is a suggestion, we can come up with more ideas.

[rene-descartes2021]

I initially looked at this from a team perspective, where one user might want changes only for their machine. Such as setting UseArtifactsOutput, or BaseIntermediateOutputPath to a tmpfs particular to their environment without forcing that choice on all the members or dealing with the overhead in using their source control tools.

I'd long viewed Directory.Build.props to be a user-supplied file, much like the .user file. The .user should not be checked into source control as it is intended for user-specific customization, even though it will technically work if checked into source control. As some maintainers of projects might version those anyway instead of propagating those settings into the relevant csproj/etc files (or equivalent means), which makes it tricker for a user of the project to make configurations to their liking.

I also ran into this problem in consuming a project as a git submodule which had its own Directory.Build.props, which resulted in my customization being ignored. An inconvenience to work around as a consumer.

EDIT: Looks like the documentation I linked on the .user file was removed since I last looked.

[alexandrehtrb]

We can also merge nuget.config properties into this new solution file format.