Source Index and pack .pdb files into regular .nupkg

[ctaggart]

Watching Deep Dive: The Future of .NET on the Server from TechEd, at 0:45:05 a discussion about *.symbols.nupkg begins. I think a better design is to source index the .pdb files and put them in the regular .nupkg. This has some advantages:

• better traceability to the actual source server, in this case it is GitHub
• it eliminates the need to use symbol servers and any performance penalty using them
• it eliminates using a separate source server like SymbolSource.org, in this case GitHub is used

I wrote a library named SourceLink that helps automate this. Thanks for being open source and moving to GitHub! I'll try to put together and example that better explains what I'm talking about. I just want to see if ya'll may be open to this.

[Eilon]

We want to keep the sizes of the regular NUPKGs that users use to be as small as possible - I think that's the main benefit of the separate .symbols.nupkg. We are looking at ways of having better/cleaner mappings between the built DLLs and the original source location to make debugging easier, however.

[ctaggart]

This would definitely provide better/cleaner mapping between the built DLLs and the original source location.

I made a little bit of progress on coming up with an example. I created an appveyor.yml to build the KRuntime. AppVeyor even creates a nuget feed for the artifacts. My question becomes, how do I install this custom build using kvm?

http://stackoverflow.com/questions/24443933/how-do-i-install-a-custom-build-of-asp-net-vnext-kruntime

Once that is figured out, the next step would be for me to figure out how to hook into SourceLink source indexing to the build.

[davidfowl]

kvm install {pathtoyourcustombuild}

[davidfowl]

I definitely think there should be a way to do this but baking it into the runtime isn't the best way to go about it. It's something you would do as a post build step. Also what Eilon said, you don't always want the PDB in the same package but it should be optional.

[ctaggart]

Why don't you always want the PDB in the same package? It allows debugging and access to the source if you index it.

[davidfowl]

Because PDBs can be huge. Why don't all the packages on nuget today have pdbs in them? Everybody understands that its nice to be able to debug packages but I don't think people always want to bloat the package size with pdbs and potentially the source. That's why it's a separate package.

I do think there's a scenario where you do want to put them together but like I said, it cannot and will not be the only way to work.

[ctaggart]

I'd like to discuss this a bit while here at the summit. :)

[Eilon]

@davidfowl is at the Summit all week, so feel free to corner him 😄

[Eilon]

@ctaggart @davidfowl did you end up discussing this? I still don't see the system putting PDBs in the main NUPKG, which can already be a bit large when you have cross-compiled assemblies in there. Add to that N number of PDBs, and you end up with super huge NUPKGs.

[ctaggart]

I didn't get a chance to. It does make them bigger, but it makes the open source projects much more open source. It is totally worth it. I really like source servers, but not symbol servers. I think the pdb files should be distributed with the nupkg files. May be NuGet 3 can make some design changes to accommodate so many cross-compiled assemblies and their xml and pdb files.

http://ctaggart.github.io/SourceLink/

For SourceLink, I'm currently working on an issue and a SourceLink.SymbolStore library that would help:

Enable Go To Definition (F12) should go to source if source symbols are available
That would be kind of awesome right!? Packaging the pdb files would enable this.

[davidfowl]

@pranavkm I think we should do this with our builds. Source link to github. Maybe we should file this in universe. It would require that we ship the pdbs in the package though.

[ctaggart]

Awesome! Given that not everyone is using FAKE, I worked this weekend on a SourceLink.exe ctaggart/SourceLink#53. That should make it easier to integrate with Sake and your existing build system. It will be available and working on NuGet and Chocolatey in a day or two. Right now, the arguments are just stubbed out.

[davidfowl]

Closing this out as it's been moved to universe.