Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Why does ProGet reject my symbols package?
-
I'm attempting to create a source+symbols package in ProGet, and I'm being told that my user doesn't have permission to overwrite a package. In the documentation, it is clearly stated that *.symbol.nupkg are supported (generated with the -symbols option to nuget pack):
Debug Into Internal NuGet Packages With ProGet:
The developers who write the shared library have the choice to build either two NuGet packages as documented in the NuGet packaging conventions or they can include all files in a single package. If you chose to use the two package convention one package must contain the required library and supporting files and the second must contain the symbols (PDB files) and it should also include the source code files placed in a folder named "src". ProGet will only display the package that contains the library in its feeds, the symbol/source package will not be visible as long as it follows the NuGet naming convention (.symbols.nupkg).
When I attempt to publish the .symbols.nupkg file (after pushing the main .nupkg), however, I get this:
'There was an error processing the request: The package mypackage.0.22 already exists and the user Anonymous does not have the Feeds_OverwritePackage privilege.'.
Product: ProGet
Version: 2.2.10
-
Hi Mark,
We should probably update/clarify that documentation. As of NuGet 2.0, the file name is no longer sent when nugget.exe does a PUT to the server; all that's sent is the PackageId. Thus, there's no way to tell if you uploaded a file called MyPackage.4.1.nupkg or MyPackage.4.1.symbols.nupkg.
We may alter the behavior to try to merge the packages, but this doesn't seem to reliable to do, since it can be difficult to judge the intent from just the files within the .nupkg zip file. We're open to feedback on how to handle this problem.
In the mean time, you can create a separate feed for symbols or just use a single package that has both. the latter is probably easiest, since ProGet will strip the symbol files out on download anyway.
hope that helps,
Steve
-
Hi Steve
Packaging a project using the -symbols param creates the *.nupkg and the *.symbols.nupkg 'zip' files.
Investigating these seems to indicate that the symbols file contains everything of the normal nupkg as well as the as the 'PDB' nad all of the source.Am i to assume that i should/can simply push the symbols package and get excatly what you describe as:
or just use a single package that has bothThomas
-
According to the NuGet docs on Creating and Publishing a Symbol Package, the .symbols.nupkg should contain only DLL, PDB, XMLDOC and source files. The regular .nukpkg should contain everything but PDB. (you can see why this is hard to merge!!)
So, I guess the "-symbols" option will not include other files, like content? It's hard to say, and I wouldn't be surprised if the behavior of that option changed from NuGet version to version.
While the separate symbols should work for you (until you add content or the behavior changes), it's probably just easier to do just do a single "pack" and push that one file (including pdb).
Keep in mind, it's just all just a .zip file, so, whatever works easiest for you.
-
Hi Steve.
Packaging with the -symbols tag does indeed create a package that contains the exact same files as the normal nuget package PLUS source and PDB files.
At least that is what happens when i use nuget.exe v. 2.8
Thomas
-
Hi
To recap for future reference.To push a package containing symbols and sourcecode the following has been tested and worked fine with nuget 2.8:
- Create nuget package using: nuget pack foo.csproj -Symbols
- Alternatively use: nuget pack foo.spec -Symbols
The above command will create two nupkg. The one decorated with the word symbols does contain all libs as well as the sourcecode and PDB files.
You cna check yourselfes by opening hte nupkg in something like winzip or 7zip, since the package is basically a zip file.- Push the symbols package to proget.
- check the package on the feed. If the symbols server is activated the package info will show that symbols and source are available.
Follow the Inedo guide on how to add The Proget symbol server support into Visual Studio.
Food for thought.
My, very quick test, shows me that a package build in the .NET 4.0 framework, of course works fine in a .NET 4.5 project, but i could not use the symbols to debug.
I tried to remove the package, downgrade my test project to .NET 4.0 and reinstall the package.
Now i could debug nicely into the source.
Bottomline. The symbols package and the project that uses it must be on the same .NET version for the symbols to work. Symbols compatibility does, apparently, not span framework versions, even thou the frameworks themselves are backwards compatible.Thomas