Enable opt-in "GeneratePathProperty" metadata on a PackageReference to generate a per package MSBuild property to "Foo.Bar\1.0\" directory

[jeffkl]

Problem Statement

Some packages' layout does not conform to the best practices. Consumers of these packages can guess the path with something like this:

<ItemGroup>
  <PackageReference Include="Foo" Version="1.0.0" />
</ItemGroup>

<PropertyGroup>
  <FooTool>$(NuGetPackageRoot)\Foo.Bar\1.0.0\tool\foo.exe"</FooTool>
</PropertyGroup>

The Foo package only has a tool folder with an EXE that I want to execute but the package author did not include any build\Foo.props that sets a property to the path of the package. So I have to derive the path based on the version. This causes some headaches when we update versions because the version value is in two places. You can use properties instead but that break Visual Studio Package Manager.

Proposal

Add a CreateProperty metadata item to <PackageReference /> which is the name of an MSBuild property to create that points to the root of the expanded package.

<ItemGroup>
  <PackageReference Include="Foo" Version="1.0.0" CreateProperty="PkgFoo" />
</ItemGroup>

The .g.props file would then contain:

  <PropertyGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
    <PkgFoo Condition=" '$(PkgFoo)' == '' ">C:\Users\Bob\.nuget\packages\foo\1.0.0</PkgFoo>
  </PropertyGroup>

And the above example can become:

<PropertyGroup>
  <FooTool>$(PkgFoo)\tool\foo.exe"</FooTool>
</PropertyGroup>

This would only be useful for packages that are non-standard which should be a minority. I am concerned that if we add this feature that it will just perpetuate bad packages. However, the reality is that we have countless code bases which consume packages that could benefit from this feature.

It would not work for transitive dependencies. If you wanted a property you would need to add an explicit package reference.

I am willing to contribute this and have a prototype already coded up.

[jeffkl]

FYI @AndyGerlicher @kingerja

[AndyGerlicher]

I think this is a really good compromise. We're seeing bigger repos try to migrate to PackageReference internally and it's causing a lot of pain for little things like this, especially when a package hasn't been updated in years and the owner has no interest in conforming. I'd heard the proposal of making every package have a property available, but I think that could lead to worse behavior by default. I like this a lot.

[rrelyea]

There is something like this that NuGet already does. But only in some cases.
Let's remember that, and understand if we should continue to enhance that existing feature … first.
I believe that may solve the same problem.
(cannot recall right now...but can dig into this soon...)

[rrelyea]

See previous work here: #5975

We discussed in person with @jeffkl and msbuild team...

Decided:
Given id of My.Package, if it had a tool folder, $(PackageToolDir_My_Package_Name) would be created in *.nuget.g.props
That would be true of all projects that transitive reference that package.
We'd also support a ExportPathVariable="PackageDir_MyFolder" attribute on PackageRef that would enable the user to request that a PackageDir prop, of the given name, be created.

More work needed:
Would PR project system need any changes?
Would PR nomination from SDK team flow the data correctly?

[jeffkl]

@rrelyea et al, can we close on the name of the attribute you want to use? Options we've discussed:

<PackageReference Include="PackageA" Version="1.0.0" PropertyName="PkgPackageA" />

<PackageReference Include="PackageA" Version="1.0.0" MSBuildPropertyName="PkgPackageA" />

<PackageReference Include="PackageA" Version="1.0.0" ExportProperty="PkgPackageA" />

<PackageReference Include="PackageA" Version="1.0.0" ExportMSBuildProperty="PkgPackageA" />

<PackageReference Include="PackageA" Version="1.0.0" ExportVariable="PkgPackageA" />

<PackageReference Include="PackageA" Version="1.0.0" CreateMSBuildProperty="true" />

<PropertyGroup>
  <NuGetGeneratePackageProperties>true</NuGetGeneratePackageProperties>
</PropertyGroup>

[jainaashish]

one more option PkgPathPropertyName

[jainaashish]

PR# NuGet/NuGet.Client#2271 has been merged to dev. Once approved, will also merge into 15.9.

[jeffkl]

@jainaashish how do we get approval for 15.9? We need to get this in ASAP but haven't figured out how you want to go about it.

[jainaashish]

@jeffkl I'm not sure what is the whole process to get this approve for 15.9... may be @DoRonMotter can help here?

[wli3]

There should be a block on normal project PackageReference a PackageType=DotnetTool? So how could user use it in their csproj? Or all these internal package don't have the PackageType

[dasMulli]

Once approved, will also merge into 15.9.

Did this happen?

[jainaashish]

Yes, this has been merged for VS 15.9 with NuGet/NuGet.Client@e082b2b