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.

[MiYanni]

While there is technical feasibility to this, there are practical reasons why this won't happen, unfortunately.

• SLN (and now also SLNX) is primarily a Visual Studio file. No one is required to have an SLN file to build their projects. So, the dotnet org doesn't have direct ability to make changes here.
• Directory.Build.props/.targets is an MSBuild file. There is a point in the MSBuild pipeline when it gets processed. SLN/X is not an MSBuild file in this way. To change SLN/X to be an MSBuild file would require massive tooling changes.
• You can override D.B.p/t hierarchically. Meaning, a nested folder with project will always use the D.B.p/t in the folder or above it. SLN doesn't have a capability like that.
• For the NuGet.config file, that is owned by the NuGet team. It also doesn't take part in MSBuild directly, but is more an indirect file through NuGet as MSBuild interacts with NuGet.

We're actually discussing making something similar to this concept, but specifically for dotnet build and tooling. But that concept is to avoid adding more to global.json and doesn't have to do with these existing files. You can find that design here: dotnet/designs#328

TLDR: These files are owned by different teams and used with different tools and processes. They're not directly "dotnet" files so we can't really do anything here without largescale changes across multiple teams and products.