Error in AppVeyor CI because NUPKG is not produced

[PlagueHO]

An error is occurring at the end of the AppVeyor CI build process. It appears that the build is not producing the Nuget package:

[tysonjhayes]

Took a few minutes to poke at this.

When I run this on my local machine I can't actually reproduce it. If you look at the image you can see all of the produced files are appended with 3.1.43.0.

However the nupkg file does not have the final .0 - why is beyond me. I set $env:AppVeyor_Build_Version on my local machine to match it produces the file correctly.

The way I see it we have to quick/dirty ways to fix.

1. Modify this line to not include the build number. I have no idea what that breaks but doesn't seem great to me.
2. Modify the next line to not specify the exact file name but filter on all nukpg files. ie:

Get-ChildItem -Path "$env:APPVEYOR_BUILD_FOLDER" -Filter '*.nupkg' | ForEach-Object -Process {
    Push-AppveyorArtifact $_.FullName -FileName $_.Name
}

Downside with this one is we now upload all nupkg files which means if we generate more then the one we might end up with more then we intend.

3. Through some black magic we modify the build not to end in a zero? ¯\(ツ)/¯

Not sure which is better really.

[PlagueHO]

@tysonjhayes - I think I've found the problem:

• Nuget.exe v3.5.0.1938: This is the version downloaded by AppVeyor by this line. It produces a NUPKG with the trailing 0 stripped off.

• Nuget.exe v3.4.3.855: This is the version I have on my machine - came with VS2015. It produces a NUPKG with the trailing 0 retained.

So it looks like this is a behaviour that is implemented in Nuget 3.5 - although I haven't been able to find any specific mention of it.

I did a quick test and downloaded the 3.4.4 Nuget.exe from https://dist.nuget.org/win-x86-commandline/v3.4.4/NuGet.exe and gave that a try. It retains the trailing 0.

So I think the solution might be to specify the 3.4.4 version of Nuget.exe in the AppVeyor.yml:

 - appveyor DownloadFile https://dist.nuget.org/win-x86-commandline/v3.4.4/NuGet.exe

Whatcha reckon?

[johlju]

I got the same error over at xSQLServer. So I wait to see what your solution is a do the same :)

In the appveyor.yml in xSQLServer it is specified a minimum version, so I could also change that to a specific version.

@PlagueHO great work finding that!

[johlju]

Hmm.. in xSQLServer its using Install-PackageProvider so I guess I have to change the entire row to solve this one.
But strangely this started happen on the December 31, on December 28 the build was passing, but from December 31 that the error appears. And the same version of package provider is being used. I guess some internals was changed.
I will try @PlagueHO solution this evening.

[johlju]

I have tested a bit...

When using "my own" AppVeyor connected to my fork of xSQLServer it fails when I push to my fork. In these two tests I printed out the version of the Nuget.exe. In the last I also printed the nuspec to see if it contained the right version. It did.

Failed with Nuget v3.4.4.1321:
https://ci.appveyor.com/project/johlju/xsqlserver/build/4.0.315.0#L4551

Failed with Nuget v3.4.3.0855
https://ci.appveyor.com/project/johlju/xsqlserver/build/4.0.316.0#L4015

But if I actually send in a PR to xSQLServer then it is working without any change to the .yml. Becuse it does not do the build step I guess:
https://ci.appveyor.com/project/PowerShell/xsqlserver/build/4.0.734.0#L3631

But when I merge code into 'dev' it is failing again (without any change to the .yml)
https://ci.appveyor.com/project/PowerShell/xsqlserver/build/4.0.730.0

I would like to see this working on my fork before merging any changes into dev. I can't get the 3.4.x version to work for either version that you tried.
So only way I see now is actually removing the last '.0', or filter on "$($env:APPVEYOR_PROJECT_NAME)*.nupkg" as @tysonjhayes suggest.

One thought though. Is there a nuget.exe somewhere in the build worker that is used, and not the one downloaded to the project folder 🤔

[PlagueHO]

@johlju - that is very odd! I'm looking into this further. Great investigation!

FYI: I think the last two links are transposed (the last one shows a successful run because the build is skipped, but the second to last is failing because of the missing .0).

[johlju]

If I change the .yml to the following it works; https://ci.appveyor.com/project/johlju/xsqlserver/build/4.0.318.0#L4046

      $nuGetPackageName = "$($env:APPVEYOR_PROJECT_NAME)*.nupkg"
      $nuGetPackagePath = (Get-ChildItem $nuGetPackageName).FullName

But then I tried to force it to use the nuget.exe in the project folder. And it WORKED!
https://ci.appveyor.com/project/johlju/xsqlserver/build/4.0.319.0#L4003

& "$($env:APPVEYOR_BUILD_FOLDER)\nuget" pack ".\$($env:APPVEYOR_PROJECT_NAME).nuspec" -outputdirectory .

@PlagueHO @tysonjhayes Can you see if this works for you as well? If so then there is a nuget.exe in the build worker that messes things up... maybe?

Do I get a local nuget.exe from Install-PackageProvider? 🤔 I will try to revert the code and see.

[PlagueHO]

I notice SharePointDsc uses the "latest" URL for Nuget.exe as well. But it doesn't look like it has been changed/rebuilt since mid Dec last year. @BrianFarnhill - have you by any chance run across this issue (Nuget stripping off .0 from end of the version number in the NUPKG filename).

[PlagueHO]

@johlju - good detective work! There is a Nuget.exe installed by default in the AppVeyor build worker. I'm not sure which version though.

However, in xNetworking (and SharePointDsc) one of the first steps we perform is to download a the latest copy of Nuget.exe from Nuget.org into the build folder. However, we use this code to perform the Nuget Pack. So I'm not certain which copy is being used here - I'd actually like to refine this code so we are enforcing the copy being used.

You are right: It does sound like this is just a situation where multiple copies of Nuget.exe end up being available and more care and control needs to be put in to ensure the correct (3.4.4) version is being used.