Pushing to SymbolSource: The request was aborted

Nov 9, 2011 at 5:09 AM


I'm trying to push my symbols package but it keeps giving me the same error:

NuGet.exe push "F:\(My Path)\Rxx.1.2.4329.35077.symbols.nupkg"

Pushing Rxx 1.2.4329.35077 to the symbol server (http://nuget.gw.symbolsource.org/Public/NuGet)...

The request was aborted: The request was canceled.

Note that pushing the regular package works fine.  It even attempts to push the symbols package automatically, as documented, but it fails with the same error above.

Any ideas?  Is there a log option or some way to get more information about the error?


Nov 9, 2011 at 9:08 AM

Try running it under Fiddler to see what really happens. Are you behind a proxy?

Nov 9, 2011 at 4:32 PM

I'm not behind a proxy.  Good idea to use Fiddler though, thanks.

NuGet.exe is making two requests to http://nuget.gw.symbolsource.org.  The first request returns a 404 error:

GET /Public/NuGet HTTP/1.0

[System.Web.HttpException]: The controller for path '/Public/NuGet' could not be found or it does not implement IController.... [snip]

The second request no longer fails with "The request was aborted"; however, it's now returning a 500 error:

POST /Public/NuGet/PackageFiles/(Is this my **private** API key in a plaintext URL?)/nupkg HTTP/1.0

Package submission failed:
System.InvalidOperationException: Source file f:\...snip...\Build\Properties\ContractExtensions.cs not found for image file Rxx.
  at SymbolSource.Processing.Tools.PackageValidator.Validate (IDirectoryInfo directoryInfo) [0x00000] in <filename unknown>:0
  at SymbolSource.Server.Management.WebService.CreateJob (SymbolSource.Server.Management.Caller caller, System.Byte[] zipContent) [0x00000] in <filename unknown>:0

 - mismatched DLL/PDB files or missing source files (above message should detail which)
 - general connectivity errors or unexpected behaviour of SymbolSource servers

This is a strange error because the ContractExtensions.cs file is actually a linked file in the project's Properties folder, and when I build the symbols package using NuGet.exe it automatically resolves the link and copies the source file into the project's Properties folder under the src folder in the package.  Is this a bug in NuGet?  Perhaps it's supposed to include the file in its original source location, because symbol files use full paths.

- Dave

Nov 9, 2011 at 4:34 PM


It would also be nice if NuGet.exe offered a command to run something like that SymbolSource.Processing.Tools.PackageValidator tool on the client so that I can verify packages as part of my build process instead of waiting until it fails on the SymbolSource server.


Nov 9, 2011 at 5:45 PM

It should be reasonably easy to add a command to NuGet.exe that performs symbolsource package validation - http://devlicio.us/blogs/rob_reynolds/archive/2011/07/15/extend-nuget-command-line.aspx


Nov 9, 2011 at 6:29 PM
Edited Nov 9, 2011 at 6:34 PM

The linked file issue appears to be a bug in NuGet.  Specifically, the NuGet.Commands.ProjectFactory.GetTargetPath method is called by the AddFiles method, which is called with the Compile items group to add source files to the src folder in the symbols package.  GetTargetPath returns Link metadata as the target path in the package, but I'm assuming that the .pdb file uses the path of the actual source file, not the link.  Can anyone confirm this?

For example, my solution folder layout looks like this:

				Link: ContractExtensions.cs

NuGet.exe creates a symbols package that includes ContractExtensions.cs in the target location, not the source location:


Since the .pdb stores the full path of the original source file's location, I'm assuming that NuGet.exe should be generating the following structure instead:


Note that I've actually customized my build process though to include the source code for multiple targets in the same platform, so actually my package looks like this (other targets excluded):


I'm assuming that inserting the Rxx folder isn't causing the error that I'm receiving from SymbolSource.  Is it?


Nov 9, 2011 at 7:19 PM

Your diagnosis is 100% correct. I remember noticing this some time ago, and even raising it with the NuGet guys, but I think it was during the busy time right before announcing symbol support, so we must have forgotten to file an issue. Can you please create one on CodePlex?

As for validation, you can do it today with NuGet Package Explorer and our plugin: http://www.symbolsource.org/Public/Blog/View/30. It should be very easy to port it as a nuget.exe extension (basically copy-and-paste) and we wanted to do that eventually. But you could also contribute it yourself, as this code is open source: https://github.com/SymbolSource/Integration.NuGet.

Nov 9, 2011 at 7:23 PM

I have been thinking about making it such that NuGet Package Explorer and nuget.exe can share the same set of package validation plugins. There're a few technical issues due to the fact that NPE and nuget.exe declare core types in different assemblies.

Nov 9, 2011 at 9:19 PM

Thanks for all the replies.

Manual validation would be fine since I'm using Package Explorer already, so the plugin seems like it's just what I need; however, the download link is broken :P

- Dave

Nov 10, 2011 at 4:16 PM
Edited Nov 10, 2011 at 4:17 PM

Ups, that's not good. I'll check that but in the mean time I would suggest NPE 2.5 from CI that can download plugins automatically from a NuGet feed. You'll see the SymbolSource plugin available there.

Nov 23, 2011 at 5:19 PM
Edited Nov 23, 2011 at 5:25 PM

i'm trying to push to the normal nuget server (nuget push *.nupkg) It's a 30 mb package and after a few minutes I get the canceled notification. Did you solve your issue?

when I load up fiddler I get a 302 from go.microsoft then a 403 from packages.nuget.org then a 404 from packages.nuget.org with my apikey in the url. This doesnt' happen when fiddler isn't running.

Nov 23, 2011 at 5:30 PM


I started this discussion specifically about problems with deploying a symbols package.  You may want to start a new discussion.

- Dave

Jul 16, 2012 at 2:55 PM
Edited Jul 16, 2012 at 2:57 PM


I'm setting up NuRep as private symbol package repository. But I'm running into an issue with linked files similar to this thread and http://nuget.codeplex.com/discussions/278801.

It looks to me like the NuGet Symbol packages have the (logical) source file structure from the project, but they should be using the physical structure (as in the PDBs).

For example:

My project (C:\MyProject\Project1\Project1.csproj) has file Foo\Bar.cs (logical path) which is linked to C:\MyProject\Project2\Bar.cs (physical path).

NuGet with -Symbols generates: src\Foo\Bar.cs
PDB contains: C:\MyProject\Project2\Bar.cs

There is no way we can unambiguously map the PDB path to the logical/NuGet path.

How does SymbolSource solve this ? Do they ?

I think NuGet should be generating this as src\Project2\Foo\Bar.cs.

- Steven


Update: I also created an issue for this: http://nuget.codeplex.com/workitem/2432

Jul 17, 2012 at 4:14 PM

If it's the only Bar.cs file in that package, SymbolSource will consider it a match. If there are more Bar.cs files, it will follow the folder structure of the PDB path towards root (drive) folder to find a common parent and use the resulting relative path inside the src folder.

There is nothing we can do about nuget.exe generating incorrect paths when building from a csproj with linked files (well apart from contributing a fix).