False NU5129 raised when a backward slash is involved in the path.

[wli3]

Please read the following information before posting the issue.

After updating to 3.0.100, we get this in the CI. It is fine on mac and Windows

/usr/share/dotnet/sdk/3.0.100/Sdks/NuGet.Build.Tasks.Pack/build/NuGet.Build.Tasks.Pack.targets(198,5): error NU5129: - At least one .targets file was found in 'build/netstandard2.0//', but 'build/netstandard2.0/System.CommandLine.DragonFruit.targets' was not. [/home/vsts/work/1/s/src/System.CommandLine.DragonFruit/System.CommandLine.DragonFruit.csproj]
/usr/share/dotnet/sdk/3.0.100/Sdks/NuGet.Build.Tasks.Pack/build/NuGet.Build.Tasks.Pack.targets(198,5): error NU5129: - At least one .props file was found in 'build/netstandard2.0//', but 'build/netstandard2.0/System.CommandLine.DragonFruit.props' was not. [/home/vsts/work/1/s/src/System.CommandLine.DragonFruit/System.CommandLine.DragonFruit.csproj]
/usr/share/dotnet/sdk/3.0.100/Sdks/NuGet.Build.Tasks.Pack/build/NuGet.Build.Tasks.Pack.targets(198,5): error NU5129:  [/home/vsts/work/1/s/src/System.CommandLine.DragonFruit/System.CommandLine.DragonFruit.csproj]
    0 Warning(s)
    1 Error(s)

And this fixed it. Looks like PackagePath no longer tolerate backward slash on ubuntu

Details about Problem

dotnet.exe --version (if appropriate): 3.0.100

[nkolev92]

@wli3

I assume the issue specifically is what the warning is raising?
Did you try specifically no warning NU5129?

I'd venture a guess that PackagePath is supported but the warning shouldn't be raised.

[wli3]

We fixed it by changing it to forward slash. But It is a regression from 3.0.100.

[nkolev92]

Can you be more specific?
Regression from version "X" to "Y"?

What's X and what's Y? The comments suggest 3.0.100 is the working version.

[wli3]

Sorry, in 2.2.300 PackagePath="build\$(TargetFramework)\" works, while it not longer works in 3.1.100

The upgrade from 2.2.300 to 3.1.100 is caused by azure devops automatic updating images.

[nkolev92]

Thanks.
Will investigate to confirm all the assumptions.

[nkolev92]

The warning is not accounting for the path separators correctly here; https://github.com/NuGet/NuGet.Client/blob/48f67796ff38e98e3dfe4ab55fce000577b74fea/src/NuGet.Core/NuGet.Packaging/Rules/UpholdBuildConventionRule.cs#L97

An example of how things should be handled can be found here: https://github.com/NuGet/NuGet.Client/blob/48f67796ff38e98e3dfe4ab55fce000577b74fea/src/NuGet.Core/NuGet.Packaging/Rules/ContentFolderInPackageReferenceProjectRule.cs#L24

We should handle this in 5.5...//cc @rrelyea

[ChristophLindemann]

Also, maybe you should not check on the source files name and folder, but on the PackagePath

Because right now it will fail, if you add a file "somewhere\foo.props.template" with a packagepath of "build/the.package.id.props"

EDIT: See comment below

[zivkan]

That surprises me. Pack validations only have visibility of the path in the package. So if a packed file is renamed as part of the pack, the validation should have no way of seeing what the original file name was.

[nkolev92]

I think @zivkan is correct.
By the time this check is performed, the package is already created.
Pretty confident that we don't look at the source by then.

[ChristophLindemann]

@zivkan & @nkolev92
Please disregard my previous comment about the package path:

Also, maybe you should not check on the source files name and folder, but on the PackagePath

Because right now it will fail, if you add a file "somewhere\foo.props.template" with a packagepath of "build/the.package.id.props"

As I can not reproduce it in a clean demo project. So I must have messed something up in my other project.

[ChristophLindemann]

@zivkan & @nkolev92

I have managed to create a repro project. Somehow the source Identity comes into play.

The following succeeds

PackTask
        PackageFiles
            build\A.Some.Props.File.props
                BuildAction = None
                Link = build\A.Some.Props.File.props
                Pack = true
                PackagePath = build/
            build/NU5129.Build.Props.Problem.props
                BuildAction = None
                Link = build\NU5129.Build.Props.Problem.props
                Pack = true
                PackagePath = build/NU5129.Build.Props.Problem.props

And this fails:

PackTask
        PackageFiles
            build\A.Some.Props.File.props
                BuildAction = None
                Link = build\A.Some.Props.File.props
                Pack = true
                PackagePath = build/
            build\Package.props.default
                BuildAction = None
                Link = build\NU5129.Build.Props.Problem.props
                Pack = true
                PackagePath = build/NU5129.Build.Props.Problem.props

You can find the code in the following repository NU5129-build-props