Support common output directory root in SDK out of the box

[tmat]

Currently, new projects using SDK build into per-project bin and obj directories. That's good for simple projects that don't participate in CI. For repos that build using CI servers it is often a requirement to produce all outputs under a single root directory with following (or similar) layout:

$(RootOutputPath)\$(Configuration)\bin\$(MSBuildProjectName)
$(RootOutputPath)\$(Configuration)\obj\$(MSBuildProjectName)
$(RootOutputPath)\$(Configuration)\packages

We have seen countless repos with build systems that are customized to do so, each in a different way. Such build customization is usually hard to get right.

I propose to add an out of the box option to the SDK that allows customers to create such repo layouts trivially.

The $(RootOutputPath) could perhaps be specified via implicit Directory.Build.props import feature: dotnet/msbuild#222.

Perhaps we could also consider $(RepositoryRootPath) a well-known property that has a documented meaning. It's a generally useful property to have, imo.

To summarize I propose the user has the option to set the following properties in Directory.Build.props:

<!-- Default value for configuration is set after Directory.Build.props is imported -->  
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>

<RepositoryRootPath>$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)\'))</RepositoryRootPath>
<RootOutputPath>$(RepositoryRootPath)artifacts\$(Configuration)\bin\</RootOutputPath>
<RootIntermediateOutputPath>$(RepositoryRootPath)artifacts\$(Configuration)\obj\</RootIntermediateOutputPath>

And the SDK uses these variables to set the output paths like so:

<PropertyGroup Condition="'$(RootOutputPath)' != ''" >
  <BaseOutputPath Condition="'$(BaseOutputPath)' == ''">$(RootOutputPath)$(MSBuildProjectName)\</BaseOutputPath>
  <OutputPath>$(BaseOutputPath)</OutputPath>
</PropertyGroup>

<PropertyGroup Condition="'$(RootIntermediateOutputPath)' != ''" >
  <BaseIntermediateOutputPath Condition="'$(BaseIntermediateOutputPath)' == ''">$(RootIntermediateOutputPath)$(MSBuildProjectName)\</BaseIntermediateOutputPath>
  <IntermediateOutputPath>$(BaseIntermediateOutputPath)</IntermediateOutputPath>
</PropertyGroup>

[tmat]

@srivatsn @nguerrera
/cc @ManishJayaswal @jaredpar

[jaredpar]

Very much agree. This is pushing developers to have a correct build by default. By correct I mean a build where by a given output path is only written to exactly once. Should make this as easy as possible for developers to opt into.

Note: Why use $(RepoOutputPath) here instead of $(BaseOutputPath)?

[tmat]

@jaredpar $(BaseOutputPath) is a per-project setting (as are all the other output variables that are currently used). $(RootOutputPath) is per-repo setting. Also we need an indicator that the repo is using a common root output as opposed to per-project bin/obj dirs. $(RootOutputPath) would be such indicator -- if set the layout is as proposed above.

[jaredpar]

$(BaseOutputPath) is a per-project setting (as are all the other output variables that are currently used).

I don't really see a difference between project and solution level settings. The only real difference is whether MSBuild is targeting a solution or a project during a build.

Concrete example: Assuming Util.sln contains Util.csproj I would expect the following commands to produce the same output:

> msbuild Util.sln /p:BaseOutputPath=c:\test
> msbuild Util.csproj /p:BaseOutputPath=c:\test

[dsplaisted]

The difference is that the solution level path (RootOutputPath as described here) needs to have the project name appended to it, while the project setting (BaseOutputPath) does not get the project name added to it.

[jaredpar]

That doesnt line up with the recomendations we came away with when meeting with various teams last week. In that meeting $(BaseOutputPath) definitely gets the project name appended to it.

[dsplaisted]

BaseOutputPath currently just defaults to bin\, so by default it is in the project folder and doesn't get the project name appended to it. It's a new property that the SDK introduces, but it's patterned after BaseIntermediateOutputPath from MSBuild which defaults to obj\.

Are you saying that the project name currently does get automatically added to it, or that that's what should happen?

[jaredpar]

Are you saying that the project name currently does get automatically added to it, or that that's what should happen?

What should happen. The discussion we had centered around $(BaseOutputPath) being a value that needed to be respected by build systems. If it was pre-populated with a value then it should be the root of the normal output tree that you would generate.

Concretely: suppose my code exists at e:\code\roslyn and I executed the following command

> msbuild Roslyn.sln

If my output was all under e:\code\roslyn\binaries then executing this command

> msbuild Roslyn.sln /p:BaseOutputPath=e:\example

Should put all of my output under e:\example\binaries. The directory structure under binaries should not change in either example, just the location where binaries is located.

[nguerrera]

We need to pick a different name and I like Tomas' choice of RootOutputPath. BaseOutputPath is patterned after BaseIntermediateOutputPath and we can't change the latter's long-existing meaning. There should also be RootIntermediateOutputPath for parity.

The logic could be something like:

if BaseOutputPath is not set
   if RootOutputPath is set
       BaseOutputPath = RootOutputPath\ProjectName\bin\
  else
      BaseOutputPath = bin\

Ditto for s/Output/IntermediateOutput/;s/bin/obj/

So you can /p:BaseIntermediateOutputPath and /p:BaseOutputPath do what they do now, and /p:RootOutputPath and /p:RootIntermediateOutputPath exhibit the behavior desired here.

[jaredpar]

BaseOutputPath is patterned after BaseIntermediateOutputPath and we can't change the latter's long-existing meaning.

What is the long term existing meaning? When discussed with MSBuild they were receptive of the semantics I outlined.

[tmat]

@nguerrera Agreed. In the proposal above I actually took it one step further and used a single variable $(RootOutputPath) to define a root path for (Base)OutputPath, (Base)IntermediateOutputPath and PackageOutputPath. If we thing it'd be useful to allow these to point to different roots then we can have mutliple Root* variables.

I'd be fine with either.

[nguerrera]

What is the long term existing meaning?

BaseIntermediateOutputPath never gets a project name appended to it to produce IntermediateOutputPath

[tmat]

@jaredpar All the properties that are set currently are per-project: either they include the project name, or are relative to the project directory.