Add Support for snupkg Symbol Packages

[RehanSaeed]

NuGet added support for the new snupkg symbol package format. It would be nice if AppVeyor picked these files up and was able to publish them to NuGet directly.

- provider: NuGet
  name: production
  api_key:
    secure: 73eFUWSfho6pxCy1VRP1H0AYh/SFiyEREV+/ATcoj0I+sSH9dec/WXs6H2Jy5vlS

[AraHaan]

Also @IlyaFinkelshteyn it seems that since early today the nuget symbol server upload started failing all my tag builds right after uploading the main part to nuget itself.

An error occurred while sending the request. The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

• https://ci.appveyor.com/project/Elskom/settingsfile/builds/20699827 (tag 1.0.0.0)
• https://ci.appveyor.com/project/Elskom/settingsfile/builds/20700201 (tag 1.0.1.0)
• https://ci.appveyor.com/project/Elskom/messagemanager/builds/20704381 (tag 1.1.0.0)
• https://ci.appveyor.com/project/Elskom/pluginupdatecheck/builds/20704028 (tag 1.0.0.0)
• https://ci.appveyor.com/project/Elskom/pluginupdatecheck/builds/20704927 (tag 1.0.1.0)

[IlyaFinkelshteyn]

@AraHaan it seems to be an issue with expired certificate at https://nuget.smbsrc.net

[AraHaan]

Ah ok, so it is their end.

[IlyaFinkelshteyn]

@AraHaan when we implement snupkg Symbol Packages (should not take long), you will be able to use NuGet.org symbol server.

[Kralizek]

@AraHaan when we implement snupkg Symbol Packages (should not take long), you will be able to use NuGet.org symbol server.

@IlyaFinkelshteyn
Is this the right issue to subscribe to be updated on the progress?

[taori]

@IlyaFinkelshteyn any updates?

[IlyaFinkelshteyn]

We are working on it right now. Cannot say specific date, but believe it should be released within a month.

[taori]

@IlyaFinkelshteyn Thanks for the update. Is there a workaround until it works built in? I can't do a manual push through cmd/ps1 without leaking nuget secret afaik?

[IlyaFinkelshteyn]

Sure, secure variables are here to make it safe :) Sorry it takes this long.

[taori]

@IlyaFinkelshteyn no problem. Glad you took the time to respond.

[taori]

For anyone who needs a workaround:

after_deploy:
- ps : Get-ChildItem .\snupkg\*.snupkg | % { dotnet nuget push $_.FullName -s https://api.nuget.org/v3/index.json -k $env:NUGET_DEPLOY_SECRET }

[bvandehey]

Any update on adding support for snupkg files without going to custom scripts?

[AraHaan]

hmmm well I think while snuget is a thing now, I might as well also use the source link thing where debugging downdloads the source code (if the file is in the repository) from the commit the build is from and so that way if one debugs without a git clone (or git installed at all) they can see the source in visual studio.

[stakx]

hmmm well I think while snuget is a thing now, I might as well also use the source link thing

AFAIK the two mechanisms are orthogonal. You still need a .pdb file for SourceLink, and you might not want to include that in the main NuGet package but in a separate... .snupkg.

[AraHaan]

Yes, that is true, however with my stuff being open source, I think it might help those that are AFAIK lazy to clone the actual project just to debug it.

However currently my problem locally is debugging a msbuild task dll that gets the git repository information and creates a custom GitAssemblyInfo.cs file that calls my special GitInformation project that provides a special attribute on the assembly that registers the assembly with the specific git repository things like the branch, clean or dirty, and the commit.

Infact said GitInformation project I would love to eventually pull into corefx as System.Runtime.InteropServices.GitInformation.

Then again this information could also be helpful if appended to the assembly's file description too.

[bvandehey]

I don't think it is a matter of laziness as much as convenience. Visual Studio already has the feature built in to discover the symbols and retrieve the source code for a nuget package. The alternative to clone the repo locally and either build it and add a project reference or reference to the assembly seems unnecessary. Perhaps VS will also prompt for a source directory and you can just reference the cloned directory but it still seems like an unnecessary step when the feature has been developed that does all of this for you.

[bvandehey]

And from Appveyor's standpoint, this is just a parameter change to the nuget pack command. I could see a checkbox added asking if snupkg should be generated and adding "-SymbolPackageFormat snupkg" to the nuget command line if selected.

[304NotModified]

Any updates @IlyaFinkelshteyn?

[304NotModified]

Please note that #2753 (comment) isn't working well in all cases. If you have another commit without a new version number, if will republish the snupkg and not the nupkg and that could "kill" the symbol packages on nuget.org (if your code has been changed)

You will check then:

One Solution is to use gitflow

[rasmus]

Any progress? According to the docs, the publish URL is merely https://api.nuget.org/v3/index.json

https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg#publishing-a-symbol-package

[IlyaFinkelshteyn]

@RehanSaeed @mauroservienti sorry my ignorance, was under impression that it is a nuget.org-only feature. If you check myget.org V3 feed it does not contain any entry of SymbolPackagePublish type and also this part of documentation does not mention .snupkg format...

How would you push .snupkg packages to MyGet with nuget or dotnet nuget command line?

[IlyaFinkelshteyn]

@stakx @StephenCleary this is error which happens when AppVeyor tries to publish nupkg file to AppVeyor Nuget feeds which happens automatically for each nuget artifact. This is unrelated to Nuget deployment to the external feed like nuget.org one.

[mauroservienti]

Thanks for your reply @IlyaFinkelshteyn. My bad, I started from the assumption that symbol packages were symbol packages regardless of the format of the packages itself. This is not the case, I’ll just disable pushing the package to MyGet till they come up with support for them.

[304NotModified]

@IlyaFinkelshteyn unfortunately there is an issue.

1. I refactor some stuff, but not gonna release this.
2. Version number is not updated
3. Publish of nupkg is skipped (correct)
4. Publish of snupkg is not skipped

result:

(same issue as here - but that was a custom script - #2753 (comment))

expected:

snupkg is skiped if nupkg is skipped

[IlyaFinkelshteyn]

Thanks for your reply @IlyaFinkelshteyn. My bad, I started from the assumption that symbol packages were symbol packages regardless of the format of the packages itself. This is not the case, I’ll just disable pushing the package to MyGet till they come up with support for them.

@xavierdecoster do you know if MyGet is going to support .snupkg format? Or maybe it is supported but we just do not know how to publish it?

CC @RehanSaeed @mauroservienti

[airbreather]

@xavierdecoster do you know if MyGet is going to support .snupkg format? Or maybe it is supported but we just do not know how to publish it?

It's the #1 voted suggested feature on myget.uservoice.com, by far.

[IlyaFinkelshteyn]

@304NotModified thank you for the catch, looking into it...

[Leszek-Kowalski]

Is this already live on appveyor.com ? I can`t get it to publish .snupkg using UI configuration anyhow. It seems to ignore the existence of .snupkg during deployment.
Exported yml:
https://gist.github.com/KoVaLL/86ddb72075f026fd1106cf93418a11c5
the build:
https://ci.appveyor.com/project/Nemesis/nemesis-textparsers/builds/25059673

[IlyaFinkelshteyn]

@kovall thanks you exposed more general issue as you see in the referenced bug. Should be fixed this week. Meanwhile it works on our mainstream images (Visual Studio 2015 and Visual Studio 2017).

[IlyaFinkelshteyn]

@kovall should work on Visual Studio 2019 now.

[Leszek-Kowalski]

@IlyaFinkelshteyn confirmed working on VS2019 image. Thanks for notification and fix 👍

[IlyaFinkelshteyn]

@304NotModified issue with duplicate publishing you described here fixed.

[teocomi]

Hey @IlyaFinkelshteyn I'm still having issues publishing the symbols to NuGet.
Added use_snupkg_format: true and set VS image to 2019, but doesn't seem AppVeyor is trying to publish them...
When the symbols were set to the symbols.nupkg format I could see it was publishing them...

Here is the current yml: https://github.com/speckleworks/SpeckleCore/blob/nuget/appveyor.yml
Here the latest build: https://ci.appveyor.com/project/SpeckleWorks/specklecore/builds/25990638
Here an old build with the symbols.nupkg: https://ci.appveyor.com/project/SpeckleWorks/specklecore/builds/25938400

Am I missing something?

[IlyaFinkelshteyn]

@teocomi regex here filters out .snupkg artifacts and leaves only .nupkg ones. You can change it to something like artifact: /.*(\.|\.s)nupkg/ or simple remove this line altogether because you do not have any other than Nuget artifacts so no need to specify them for deployment.

[teocomi]

Awesome, thanks a ton!

[dazinator]

@IlyaFinkelshteyn

regex here filters out .snupkg artifacts and leaves only .nupkg ones. You can change it to something like artifact: /.*(\.|\.s)nupkg/ or simple remove this line altogether because you do not have any other than Nuget artifacts so no need to specify them for deployment.

I changed the artifact filter to artifact: /.*(\.|\.s)nupkg/ in my appveyor.yml but that didn't work:

• build
• appveyor.yml

[dazinator]

Also removing the artifacts line completely, hasn't pushed the .snupkg package either :-(

[dazinator]

I'll open a new issue.

[navidmatin]

Does this work for a custom symbols path? It appears that it still doesn't.
I cannot get appveyor to publish a .snupkg to a myget's nuget v3 symbol's path (e.g. https://www.myget.org/F/my-private-nuget-repo/api/v3/index.json), but if I use myget's legacy symbol's path in appveyor (e.g. https://www.myget.org/F/my-private-nuget-repo/symbols/api/v2/package) it does push the package in there.

[FeodorFitsner]

@navidmatin you can use nuget command line instead of built-in deployment provider to push to v3 feed.