publish symbol package for nuget private feed package

Aug 21, 2011 at 4:19 AM
Edited Aug 21, 2011 at 8:24 PM

Is publishing a symbolsource.org package for a package pubilshed only to a nuget private feed supported?  

I tried the following command which appears to succeed = nuget push <path>\<my package>.<version>.symbols.nupkg -source http://nuget.gw.symbolsource.org/Public/NuGet and it appears to work

but when i execute the following command it appears to fail due to me needing some company name provisioned = nuget push <path>\<my package>.<version>.symbols.nupkg -source http://nuget.gw.symbolsource.org/robertob/NuGet

q1 - Do i need the latter symbolsource publishing command to succeed for things to be okay or do i need the latter to succeed for things to be working?

q2 - The documentation suggests that "NuGet push mypackage.symbols.nupkg" checks first to see that the corresponding package exists under my account on the public nuget feed which in my case isn't going to be there...unless i can publish to nuget public feed but set some flag to mark it as an unadvertised package.  Is the "nuget push -CreateOnly" flag intended for that purpose?

 

Coordinator
Aug 22, 2011 at 5:28 PM

We don’t have any support for that. I have a feeling it shouldn’t be too hard to build such a thing, but we just haven’t spent time looking into it. It’d require hosting your own private NuGet gallery and us making changes to nuget.exe to allow specifying alternative symbol servers.

Aug 22, 2011 at 7:13 PM

I think SymbolSource does provide private instances. See step 8 in http://www.symbolsource.org/Public/Blog/View/25 for some info. Maybe one of the SymbolSource guys can comment further.

Aug 22, 2011 at 8:11 PM

thanks for the responses.  Perhaps you can simply help clarify some confusion about all this.   I'm able to successfully publish to http://nuget.gw.symbolsource.org/Public/NuGet symbol packages for packages published to my private simple "read-only" nuget feed.   So is the need for a fully functionaly private nuget feed only if you want to publish the symbol package to your private symbol source location, e.g. in my case http://nuget.gw.symbolsource.org/robertob/NuGet?  

Note on symbolsource.org it wasn't obvious where the discussion and issue forums are like they are in the case of nuget.   Once i find those i can surface this questions there but they seem like something nuget users of the private simple "read-only" nuget feed would run into which is why i've surfaced them here.

Aug 22, 2011 at 8:15 PM

The little question mark icon takes you to their Google Group: http://groups.google.com/group/symbolsource. It is indeed the better place to discuss SYmbolSource, as the guys running it are monitoring it more closely.

Aug 22, 2011 at 9:49 PM

You were right about the command to publish to a private SymbolSource repository. We don't fully advertise it yet, because it requires a bit of provisioning work on our end at the moment. I will get back to you this week with what I hope will be a live beta of how we imagine things to work. Also, the discussion group that @davidebbo mentioned is the best place to ask any questions and report any issues concerning SymbolSource. We'll try to make it more obvious where to go for such matters. We try to monitor NuGet discussions too, but things do slip through unnoticed.

Aug 23, 2011 at 4:26 PM
Edited Aug 25, 2011 at 7:11 AM

thanks this helps.  

Currently i'm okay with my symbols [ and sources ] package being published in the public area [ http://nuget.gw.symbolsource.org/Public/NuGet ] as opposed to my private area [ http://nuget.gw.symbolsource.org/robertob/NuGet ] given what i read in http://symbolsource.org overviews suggests that no one can just randomly pull pdb's and sources, i.e. they are only accessible when an unhandled exception occurs in some library they have referenced where i have the symbol [ and source ] package published. 

a few questions for clarification on the vstudio symbols [ and sources ] consumer side of things that i'll post here as i expect its as much a NuGet user concern as it is a SymbolSource user concern . . .

1. when i publish my symbols [ and sources ] package using "nuget push <package>.<version>.symbols.nupkg -source http://nuget.gw.symbolsource.org/Public/NuGet" i'm expecting that i need a vstudio | tools | options | debugger | symbols | http://srv.symbolsource.org/pdb/Public entry

2. when i publish my symbols [ and sources ] package using "nuget push <package>.<version>.symbols.nupkg -source http://nuget.gw.symbolsource.org/<username>/NuGet" i'm expecting that i need a vstudio | tools | options | debugger | symbols | http://srv.symbolsource.org/pdb/Public/<username>/<hashcode> entry

q1 - are statements 1 & 2 correct?

q2 - at one point my symbols were being pulled and loaded successfully for the nuget symbol packages i had published to http://srv.symbolsource.org/pdb/Public, as confirmed by vstudio | debug | windows | modules [ ctrl-d-m], but then that seemed to have stopped working.   Is there a typical reason behind this happening?

q3 - also once i turned on symbols support in vstudio using the instructions found at http://www.symbolsource.org/Public/Home/VisualStudio | "recommended configuration" i found my f5 debug/test startup time became unacceptibly slow.  In my case i'm really only interested in symbol and source debugging support for the current project being f5 debugged/tested and the specific nuget packages i'm testing the use of or have unexpected exceptions coming from.  So i went into vstudio | tools | options | debugger | symbols and set symbol file locations to only have http://srv.symbolsource.org/pdb/Public checked and then selected "only specified modules" and in there added "<namespace of nuget packages assemblies i want to debug thru>*.dll".   After that f5 debug/test was very fast again but i don't seem to be pulling my http://nuget.gw.symbolsource.org/Public/NuGet published and http://srv.symbolsource.org/pdb/Public consumed symbol [ and source ] packages.  Any thoughts on whether or not i'm misinterpreting the results i'm expecting that i will get from setting this vstudio symbols related "only specific modules" configuration option?

Aug 23, 2011 at 4:54 PM
robertob wrote:

Currently i'm okay with my symbols [ and sources ] package being published in the public area [ http://nuget.gw.symbolsource.org/Public/NuGet ] as opposed to my private area [ http://nuget.gw.symbolsource.org/robertob/NuGet ] given what i read in http://symbolsource.org overviews suggests that no one can just randomly pull pdb's and sources, i.e. they are only accessible when an unhandled exception occurs in some library they have referenced where i have the symbol [ and source ] package published. 

I really doubt that. By crafting the right URLs, you can probably access any sources that are on there. So if your goal is to keep them secure, that's likely a bad choice. I'll let @TripleEmcoder confirm and comment on the rest.

Aug 24, 2011 at 8:30 AM
Edited Aug 24, 2011 at 8:35 AM

q1 - Yes, that's correct.

q2 - No, once it's proven to work, it should always work, we would need to debug this issue - can you provide the offending dll or at least its hash? URLs being hit in Fiddler would also do.

q3 - True, we skipped the part about setting load options to "only specified modules", it's a huge time saver. By "<namespace of nuget packages assemblies i want to debug thru>*.dll" do you mean a literal asterisk (*)? I don't think this settings supports any wildcards, you need to input all assembly names literally.

As far as the security of your code is concerned then please remember that sources are also browsable through this page http://www.symbolsource.org/Public/Metadata/NuGet/Projects - unless you "delete" the package as described here: http://www.symbolsource.org/Public/Blog/View/27 (nuget delete, or hide link on the website when logged on as package owner). You could use that as a workaround until we provide you with your own private repository.

To forge a link to the sources one would need to have the actual dll/pdb to extract its hash, so as far as this is indeed security by obscurity, it should be pretty much secure.

But still, we want to solve this appropriately this week.

Aug 25, 2011 at 1:15 AM
Edited Aug 25, 2011 at 1:26 AM

thanks for the responses that helps

i tested deleting my packages as described in http://www.symbolsource.org/Public/Blog/View/27 using the command "nuget delete <my package> <version> -source http://nuget.gw.symbolsource.org/Public/NuGet" which output the following results

    <my package> <version> will be deleted from the the symbol server (http://nuget.gw.symbolsource.org/Public/NuGet). Would you like to continue? (y/N) y
    Deleting <my package> <version> from the the symbol server (http://nuget.gw.symbolsource.org/Public/NuGet).
    Version is now hidden. It will not show up on any listing, but PDBs and sources will still be served for clients with old binaries. Go to www.symbolsource.org to delete pernamently.

given the ability to publish to my private symbols area "http://nuget.gw.symbolsource.org/<username>/NuGet", and consume it in vstudio using "http://srv.symbolsource.org/pdb/Public/<username>/<hashcode>", sounds like it is not ready just yet for primetime then this publish to public area and then delete looked promising given symbols & sources would still be available in vstudio debugging using http://srv.symbolsource.org/pdb/Public but would not be browsable at http://www.symbolsource.org/Public/Metadata/NuGet/Projects

what's unexpected though is that after executing the delete command where the output suggested everything completed okay is that i can still visit http://www.symbolsource.org/Public/Metadata/NuGet/Projects and see project names but when i click on them nothing shows up in the details view as public or hidden.  

q1  - is that the expected results following a successful delete of a project from the symbolsource public area or should i expect the project entry to get wiped as well from the metadata/nuget/projects list?

q2 - on a related note any work going on to refer to projects as packages on symbolsource so that there is synergy with the naming nuget uses or is it called project for other reasons that will remain relevant?

Aug 25, 2011 at 1:20 PM

q1 - Yes, this is how it works at the moment, there is no filtering on the project index. If you log in as the user that sent the package you'll see it on the hidden list.

q2 - Well the fact is that SymbolSource was up live well before NuGet was announced :) The notion of a project is nested very deeply in every component of the system, so it would very difficult (and misleading) to change. Also, SymbolSource is meant to host symbols and sources uploaded without NuGet, or with other package managers, such as OpenWrap.

BTW we are very close to announcing full-featured private repositories.

Aug 26, 2011 at 3:45 AM
Edited Aug 26, 2011 at 4:27 AM

thanks for the rsponses this helps.  

wrt q1/a1 you mentioned that if you log in as the user that sent the ackage you'll see it on the hidden list.  In my case i was just seeing one list at http://www.symbolsource.org/Public/Metadata/NuGet/Projects and if i click on my project entries where i hit delete there looks are not entries but there looks to be what would be a list section header "Hidden" that says "There are currently no hidden packages".   Turns out this was the result because i wasn't logged in.  Once i did the list section header "Hidden" shows my deleted / hidden packages and provided an "unhide" option so not realizing i wasn't logged into site when viewing this are looks like it was the source of my unexpected results following project symbol and source deletion.

wrt q2/a2 - i see then that makes sense.

wrt full featured private repositories that is great.   I read the post on creating an full featured private nuget gallery and that seemed a bit ownerous as compared to the private read-only nuget gallery setup process.   So being able to couple that with private symbolsource repositories will be a great combination.   Thanks for all the great work.

Aug 26, 2011 at 8:49 AM
Edited Aug 26, 2011 at 8:49 AM

I did not raise the logged in or not possibility because I was sure that the entire "Hidden" section does not show to other (or anonymous) users - we'll fix it and make it so with today's update.