[Proposal] Make Directory.Build.props more discoverable

[stevenbrix]

See #762 for a lot of good discussion on the pain people have with this file.

I love this feature, but the "magic" involved in it turns people off. We have people on our team who want to explicitly ban the use of this feature because of it.

Proposal

Have dotnet new and VS Create New Project scenarios place an empty Directory.Build.props file next to the project with a high level comment about what it does and then a link to more documentation. This way developers would at least be familiar with it even when they've never used it.

[stevenbrix]

I know this might not be the right repo for this, but since this is the MSBuild repo, I figured the team would have a vested interest in ensuring the success of their features :)

Directory.Build.props and binlogs need someone to stand on the top of Mt. Rainier and shout it out.

I'm not sure what it's like for .NET devs who have been using and following MSBuild for decades, but those coming from other build systems have a hard time discovering these features.

[memark]

I have been working professionally with .NET for almost 15 years. I only last week learned about the existence of this file. It solves quite a few problems for me, including disabling the same 4 warnings for every build config for every project in my 50+ project solution. I think it would be really helpful to generate an empty file of this sort in the templates. Just like is/was being done with web.config och appsettings.json.

[danzil]

+1 on the idea behind this proposal, to make the feature more discoverable. I think, however, the reason this is was not done before is that once you have such a file in a sub directory, you need to bridge all gaps to the root and manually include your parent directory.build.props. Once you have a gap that you don't bridge with an include, you may think the skip-parent directory.build.props applies down, but it may not, actually.

[stevenbrix]

@danzil I agree it would be difficult, but then i would at least hope that maybe File->Add New Item in VS would include an option for Directory.Build.props (and Directory.Build.targets).

But it should be possible to tell in Visual Studio when adding a project to an existing .sln and correctly have Directory.Build.props import the one up the chain like you suggest. Likewise, the dotnet cli tools has commands for adding projects and modifying .sln files that should be able to do the same.

The workflow would be

1. Create new project - Creates empty Directory.Build.props
2. Add project to existing sln - updates Directory.Build.props to include the one above it (if the relative path is further down the tree)

If you're hand editing .sln files by hand then good luck, all bets are off ;)

This should only work for .sln files created with a certain version of Visual Studio, so that existing projects have the same behavior

[danzil]

I agree. The tools need to do the right thing when dropping the file into the solution directory. At the very least, since this is a new project, the file could include a comment about this chaining that may be required.

[fredrikhr]

I'd actually also like dotnet new sln to include a Directory.Build.props file.
Especially, I regard a solution as a collection of projects, meaning Directory.Build.props makes even more sense as I usually put those two properties into them:

<?xml version="1.0" encoding="utf-8"?>
<Project>
  <PropertyGroup Label="BasePath">
    <BaseOutputPath>$(MSBuildThisFileDirectory)bin\</BaseOutputPath>
    <BaseIntermediateOutputPath>$(MSBuildThisFileDirectory)obj\$(MSBuildProjectName)\</BaseIntermediateOutputPath>
  </PropertyGroup>
</Project>

in order to have a solution-level bin and obj folder. (ref.: thnetii/repository-default)

In my default Directory.Build.props I also add the Microsoft.CodeAnalysis.FxCopAnalyzers package reference for best practice

<PackageReference Include="Microsoft.CodeAnalysis.FxCopAnalyzers" Version="2.9.8" PrivateAssets="All" />

[Cyberboss]

If anything can we include the source of properties in diagnostic output?

I just spent a long time tracking down a property that I could not find the definition for. Turns out it was defined in a Directory.Build.props above the solution. While the location of the file itself is stored in the log output, the source of the property wasn't and led to quite the headache.

[stevenbrix]

@Cyberboss, do you use binlogs from the command line? Unfortunately the ones collected in VS don't have information, but if you use command line builds, they have a "Find in Files" tab, which then lets you search for <PropertyImLookingFor to see where the property is set.

I'm also fine with Right Click->Add New Item to contain MSBuild items.

[jonadv]

I actually cant believe this file isnt showing in the solution explorer. Also pretty dumb that if this file is placed one folder outside of the solution directory, it is still read.