Error from package creation when building .NET SDK projects

[alastairs]

Description

We have Paket integrated with the .NET SDK via the bootstrapper in Magic Mode, as recommended. When Paket is invoked as part of the build on a solution containing .NET SDK projects to be packaged for NuGet, some of the projects fail with errors like the following:

C:\code\.paket\Paket.Restore.targets(210,5): error : The filename, directory name, or volume label syntax is incorrect : 'C:\code\test\TestHelpers\obj\Release\TestHelpers.1.0.0-pre-000000.nuspec;C:\code\test\TestHelpers\obj\Release' [C:\code\test\TestHelpers\TestHelpers.csproj]

As far as I can tell based on comparisons between succeeding and failing project files, it doesn't appear to be anything related to the project file or their target frameworks.

These are the .NET SDK calls being invoked on my machine:

dotnet build --no-cache $SolutionFile -c Release --version-suffix=pre-000000
dotnet publish --no-build $SolutionFile -c Release

On one branch, where I converted from NuGet to paket using the conversion tool, five projects throw this error. On another branch, where I converted from NuGet to paket manually, only three projects throw this error, a subset of the five.

Repro steps

I am not sure of the repro steps in this instance, as it happens on the first attempted build after converting the project to paket.

Expected behavior

Paket packs the projects successfully.

Actual behavior

Some projects fail with errors like the following:

C:\code\.paket\Paket.Restore.targets(210,5): error : The filename, directory name, or volume label syntax is incorrect : 'C:\code\test\TestHelpers\obj\Release\TestHelpers.1.0.0-pre-000000.nuspec;C:\code\test\TestHelpers\obj\Release' [C:\code\test\TestHelpers\TestHelpers.csproj]

[forki]

Can you please upload a zip with a repro? Alastair Smith <[email protected]> schrieb am Fr., 29. Juni 2018, 13:47:

…

Description We have Paket integrated with the .NET SDK via the bootstrapper in Magic Mode, as recommended. When Paket is invoked as part of the build on a solution containing .NET SDK projects to be packaged for NuGet, some of the projects fail with errors like the following: C:\code\.paket\Paket.Restore.targets(210,5): error : The filename, directory name, or volume label syntax is incorrect : 'C:\code\test\TestHelpers\obj\Release\TestHelpers.1.0.0-pre-000000.nuspec;C:\code\test\TestHelpers\obj\Release' [C:\code\test\TestHelpers\TestHelpers.csproj] As far as I can tell based on comparisons between succeeding and failing project files, it doesn't appear to be anything related to the project file or their target frameworks. These are the .NET SDK calls being invoked on my machine: dotnet build --no-cache $SolutionFile -c Release --version-suffix=pre-000000 dotnet publish --no-build $SolutionFile -c Release On one branch, where I converted from NuGet to paket using the conversion tool, five projects throw this error. On another branch, where I converted from NuGet to paket manually, only three projects throw this error, a subset of the five. Repro steps I am not sure of the repro steps in this instance, as it happens on the first attempted build after converting the project to paket. Expected behavior Paket packs the projects successfully. Actual behavior Some projects fail with errors like the following: C:\code\.paket\Paket.Restore.targets(210,5): error : The filename, directory name, or volume label syntax is incorrect : 'C:\code\test\TestHelpers\obj\Release\TestHelpers.1.0.0-pre-000000.nuspec;C:\code\test\TestHelpers\obj\Release' [C:\code\test\TestHelpers\TestHelpers.csproj] — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3272>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNDjZawraMchekEUnDZGAF_7ep3rmks5uBhPYgaJpZM4U85KU> .

[alastairs]

Thanks @forki, I've invited you to a private repo with a reproduction of this bug.

[alastairs]

Aha! I have found what appears to be the root cause for the issue: there are two .nuspec files in the obj\Release directory, which are listed in the error message as a semicolon-separated string. I'm guessing Paket is trying to use that string as a path without splitting it first.

[lexarchik]

I think it related to #2661

PackTest2.zip
I did some test in attached example (just netstandard2.0 project with one file) and found strange things.
In attached solution i ran
git clean -dxf; paket convert-from-nuget --force; dotnet pack --include-symbols -v diag
for two version of Paket (change version in paket.dependencies): 5.89.4 and 5.173.2

In log for 5.172.3 i see for task PackTask: Task Parameter:NuspecFile=<string with two files separated by semicolon>

In log for 5.89.4 i cant see NuspecFile parameter for PackTask. However PackTask call in Paket.Restore.targets for version 5.89.4 is identical to version 5.172.3.

I can't understand how it might work and when it was broken.

In version range [5.92.0-beta001 - 5.119.9] pack in this example fails with Cannot create a package that has no dependencies nor content.

[Genbox]

Dup of #3160

[forki]

@lexarchik I tried your sample with latest version and it actually creates the nupkgs - what issue should I see?

[forki]

@alastairs I ran paket install and dotnet build -c Release --version-suffix=pre-000000 on your test project and it created a nupkg

[Genbox]

@forki this issue is still there. It happens in my projects when using imports. I tried to create a simpler repo to recreate the issue but could not get it to work. However, I found that I have a nuget PackageReference in my imports that paket did not touch duing the "convert-from-nuget" process. I suspect that has something to do with it.

[lexarchik]

@forki dotnet pack --include-symbols still fails with

<...>\.paket\Paket.Restore.targets(213,5): error : The filename, directory name, or volume label syntax is incorrect : '<...>\PackTest2\obj\Debug\PackTest2.1.0.0.nuspec;<...>\PackTest2\obj\Debug' [<...>\PackTest2\PackTest2.csproj]

paket version 5.176.6

[forki]

Not for me. Unfortunately? Which dotnet version? lexarchik <[email protected]> schrieb am Fr., 17. Aug. 2018, 17:28:

…

@forki <https://github.com/forki> dotnet pack --include-symbols still fails with <...>\.paket\Paket.Restore.targets(213,5): error : The filename, directory name, or volume label syntax is incorrect : '<...>\PackTest2\obj\Debug\PackTest2.1.0.0.nuspec;<...>\PackTest2\obj\Debug' [<...>\PackTest2\PackTest2.csproj] paket version 5.176.6 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3272 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNIGU7s_N4XqwVMKlBUag3Iz9_CyTks5uRuEagaJpZM4U85KU> .

[lexarchik]

dotnet version 2.1.300
win10x64

[sdargaud]

I happen to have this problem too and I have seen that it occurs when launching dotnet pack twice with different versions. The clean command does not remove the old .nuspec file and the second time it finds 2 of them and it crashes. Removing the old .nuspec file fixes the problem.
Hope this helps analyzing this problem.

[NightWatchman]

I have this problem myself if I use the flags --include-symbols or --include-source in the dotnet pack command.
i.e. dotnet pack Company.Authentication\Company.Authentication.csproj --configuration Release --include-source

It seems to happen any time there is more than one .nuspec file in obj/Release. In this case the command makes both a .nuspec file and a .symbols.nuspec file and then the Paket.Restore.targets file doesn't handle it correctly.

Windows 10
dotnet version 2.2.101
paket version 5.194.0

[NightWatchman]

I'm still not able to build a package with
dotnet pack Project.csproj --include-source

dotnet version 2.2.101
paket version 5.198.0

It seems that the issue of the pack failing when there is more than one nuspec file in the obj directory is well known, and attempts have been made to address the issue by ensuring that there is only one nuspec file when it needs it. The specific case where a symbols.nuspec is generated alongside the usual .nuspec file due to the use of --include-source or --include-symbols flags doesn't seem to have been addressed to date.

Isn't there a way to have it either not generate both nuspec files, or if that's not possible, have it ignore the non-symbols nuspec file if both are present? I don't know enough about the build process to fix it.

[aaronpowell]

Tagging in another related issue: #2689