PackagePath is treated as a directory, not a file path, for files with no extension [Regression]

[natemcmaster]

GenerateNuspec changed the way it handles PackagePath in a recently nightly.

Details

NuGet product used: dotnet
NuGet version (x.x.x.xxx): ?
dotnet.exe --version: 2.2.0-preview1-007846
OS: Windows 10

Worked before? Yes, in dotnet.exe 2.2.0-preview1-007796

Repro

1. dotnet pack this project

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <PackageType>DotnetCliTool</PackageType>
  </PropertyGroup>

  <ItemGroup>
    <Content Include="prefercliruntime" PackagePath="\prefercliruntime" />
    <Content Include="License.txt" PackagePath="\License.txt" />
  </ItemGroup>

</Project>

Expected

Package layout in the 2.1.3 SDK and previous nightlies was:

 - MyApp.nupkg/
   + prefercliruntime
   + License.txt
    - lib/
       - netcoreapp2.0/
          + MyLib.dll

Actual

With the 2.2.0-preview1-007846 SDK, layout adds a folder for the prefercliruntime file.

 - MyApp.nupkg/
   - prefercliruntime/
      + prefercliruntime
   + License.txt
    - lib/
       - netcoreapp2.0/
          + MyLib.dll

[muratg]

cc @rrelyea @emgarten

[mishra14]

@rohit21agrawal can you take a look to see what caused this?

[rohit21agrawal]

this is caused as a side-effect of fixing : #5898

I believe the fix is correct actually as it fixes a scenario that couldn't be worked around before.

The scenario you mentioned can easily be fixed by including an empty packagePath:

<PackagePath></PackagePath>

or

<PackagePath>/</PackagePath>

[kkm000]

@rohit21agrawal, @emgarten, I would greatly appreciate your thoughts and suggestions on handling this change in an open-source project not pinned to an SDK version. We were going back and forth with an extra level of patch spec appearing in packages, before I finally realized that I used the latest SDK 2.1.403, but the gRPC CI, which builds packages, apparently has an earlier version.

This behavior has actually changed from the SDK version 2.1.4 to 2.1.100, shipped with the respective NuGet.Build.Tasks.Pack.dll versions 4.5.0.4 and 4.6.0.0.

My understanding is that .NET Core 2.0 is EOL, which means it's ok for us to pretend there are no SDK versions between 2.0.0 and up to but not including 2.1.300; these should just be upgraded by the user. This is good news, since the breaking change falls into this dead range. The SDK versions 1.0 and 1.1 are alive and supported, though. This means that supported SDK versions that exhibit the ante-fix ("old") behavior are all below 2.x.x, and the SDK 2.1.300 (the earliest in the Core 2.1 line) and above come with this fix ("new" behavior).

Now, it is fairly easy to find out which one we are being packaged under, because the SDK 2.1.300 and later set the property NETCoreSdkVersion to its exact version very early in the build (in the file Microsoft.NETCoreSdk.BundledVersions.props) and unconditionally, but this property does not exist in SDK 1.x up to the latest 1.1.11. Thus, if set, the property would tell me to align the packaging paths for extensionless files with the "new" behavior, at the very least to handle it somehow until the 1.x SDKs expire.

Am I making sense, and am I not falling into a possible trap? So far I have been assuming that the NuGet.Build.Tasks.Pack is firmly tied to an SDK release, so it is not possible that the user of an 1.x SDK will have the N.B.T.P somehow upgraded it to a version with the "new", post-fix behavior (except through an unsupported kluge). Is this assumption correct/reasonable?

X-ref grpc/grpc#13207

[jskeet]

I've run into this problem as well, in a slightly different way.

I have a file called LICENSE that I wish to be packed as LICENSE.txt. I would expect this to work:

<None Include="../../../LICENSE" Pack="true" PackagePath="LICENSE.txt" />

... but that creates a file called LICENSE in a directory called LICENSE.txt in the NuGet package.

It looks like I'm going to have to either rename the file (which is annoying for other reasons) or copy it to LICENSE.txt as part of our build packaging.
I really hope this is fixed in a later version...

[chtenb]

I'm using PackagePath="contentFiles\%(Filename)%(Extension);content\%(Filename)%(Extension)" to have the files in that group be packaged in a flattened fashion. However, one of those does not have a file extension (I can't change this, its 3rd party), and is its packagePath is therefore treated as a directory, under which the entire folder structure is then copied again. How can this be fixed?

For reference and context, the entire item group in my .csproj looks like

  <ItemGroup>
    <None Update="NativeArtifacts\*"
          Link="%(Filename)%(Extension)" CopyToOutputDirectory="PreserveNewest"
          Pack="true" PackagePath="contentFiles\%(Filename)%(Extension);content\%(Filename)%(Extension)" PackageCopyToOutput="true" />
    <None Include="..\LICENSE" Pack="true" PackagePath=""/>
  </ItemGroup>

The Link property is used during build to flatten the structure, and this has been working fine. However, nuget pack seems to ignore this. Using PackagePath explicitly would be a workaround, except for the problem described above.