[Bug]: Pack fails when adding readme file but not using snupkg

timheuer commented 3 years ago

NuGet Product Used

dotnet.exe, MSBuild.exe

Product Version

6.0.100-rc.1.21458.32, VS 2022 Preview 5

Worked before?

No response

Impact

I'm unable to use this version

Repro Steps & Context

Sample repo (use packbug branch): https://github.com/timheuer/alexa-skills-dotnet/tree/packbug

I'm adding the readme information via the project properties UI in Visual Studio 2022. It generates:

<PackageReadmeFile>readme.md</PackageReadmeFile> and

  <ItemGroup>
    <None Update="readme.md">
      <Pack>True</Pack>
    </None>
  </ItemGroup>

After executing dotnet pack or using right-click pack:

Severity    Code    Description Project File    Line    Suppression State
Error   NU5039  The readme file 'readme.md' does not exist in the package.  Alexa.NET   C:\Program Files\dotnet\sdk\6.0.100-rc.1.21458.32\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets  221

The file is indeed there. Video 2021-09-24_14-59-59 :

Verbose Logs

No response

anangaur commented 3 years ago

Seems like a blocking issue for README adoption using Visual Studio. @chgill-MSFT, can we prioritize fixing this for VS 2022 GA.

heng-liu commented 3 years ago

Hi @timheuer , thanks for taking time filing this issue! I could repro with your branch. I haven't looked into it much, but just tried to make the following change then seems the packing is successful: Changed

  <ItemGroup>
    <None Update="readme.md">
      <Pack>True</Pack>
    </None>
  </ItemGroup>

into:

  <ItemGroup>
    <None Include="readme.md" Pack="true" PackagePath=""/>
  </ItemGroup>

Could you try this and see if that would unblock you? Thanks!

timheuer commented 3 years ago

Yes indeed this does unblock -- I just wanted to make sure I logged the issue of what the tools are generating appearing to be invalid settings. I'm unblocked with your workaround of fixing the tool-generated proj settings.

heng-liu commented 3 years ago

Looks like the error is caused by missing PackagePath property. Do we need to call that out in our doc? @chgill-MSFT @zkat

chrisraygill commented 3 years ago

When I tried packing a README with VS 17.0 preview 5, it generated the <PackagePath> property.

Maybe project systems already fixed this?

timheuer commented 3 years ago

@chgill-MSFT put the readme.md file at the same location as the proj file and then do the same action...this seems to be the trigger. When I tried it with a file outside of that location it does appear to generate the PackagePath attribute correctly...but when the MD file is at the root project-relative path seems to be the issue.

aortiz-msft commented 3 years ago

@zkat - Could you please take a look?

chrisraygill commented 3 years ago

I was able to repro Tim's issue when adding the readme.md file to the same location at the proj file. For reference, here are a few different scenarios:

README is in same directory as proj file

README is in solution root directory

README is outside repo solution root directory

In addition to omitting the <PackagePath> element, it looks like referencing a file in the proj file directory also changes <None Include=""> into <None Update="">.

Unfortunately, this bug seems to extend to any embedded package element including icons and licenses:

Do we know if this is a bug on our side or project systems?

@miyanni who implemented the README property into the package properties menu.

chrisraygill commented 3 years ago

Confirmed that this behavior is a regression in 17.0. This scenario worked fine for icons in VS 16.11 and used the proper "include" and added the "PackagePath".

The bug exists in both 17.0 preview 3 and 5, so it was probably introduced with the new project system menu.

zkat commented 3 years ago

I guess it's a project system issue?

chrisraygill commented 3 years ago

I filed this issue in the project systems repo to track since it looks like the bug is on their side:

https://github.com/dotnet/project-system/issues/7642

Thanks for bring this to our attention @timheuer!

aortiz-msft commented 3 years ago

Transferred issue to https://github.com/dotnet/project-system/issues/7642

MiYanni commented 3 years ago

General Question: Why would an empty <PackagePath></PackagePath> item attribute have significance?

This project file is primarily used by MSBuild, and in that system, an empty value and an omission of the attribute are the same. Shouldn't that be the case here? If it isn't, it should be fixed on the NuGet packing side of things. When reading the documentation, it was not obvious that an empty value for the attribute was required; the docs made it seem like that the default for this would understand it as empty. Also, the value "/" makes this a bit more confusing too; is that would be equivalent to empty, correct?

NuGet / Home