Overview: I have been doing some reading/research to better understand symbol servers and source servers. I realize some readers may already be familiar with the topic, but for those that are not the information may prove useful. To provide the ability to easily step down into source code of referenced libraries within Visual Studio, NMaven will need to integrate with Microsoft's Source and Symbol server functionality. A high level overview can be found using the following links: http://msdn.microsoft.com/en-us/magazine/cc301459.aspx http://msdn.microsoft.com/en-us/magazine/cc163563.aspx =================================== Additional Useful Information: The source server directory in the "Debugging Tools for Windows" distribution contains a particularly useful MS Word document which provides a great deal of the details missing from the articles above. The section on "HTTP Sites and UNC Shares" is particularly interesting as it provides an alternate way to easily support source server functionality. Assuming you have installed "Debugging Tools for Windows" in the standard location the MS Word document can be found at: C:\Program Files\Debugging Tools for Windows (x86)\srcsrv\srcsrv.doc Note: You will need to install "Debugging Tools for Windows". ---------------------------------------- The MS Help files installed along with "Debugging Tools for Windows" as well as most other documentation don't really cover the use of multiple symbol servers well. The omission can lead one to the false conclusion only a single remote symbol server is supported. From Chapter 4 (Managing Symbol and Source Files) of Advanced Windows Debugging by Daniel Pravat reveals one can include as many remote symbol servers in the sympath as desired. These can also be URLs not just UNC paths. (I may have found this in the MS Word document mentioned above.) Title: Advanced Windows Debugging by: Mario Hewardt; Daniel Pravat Publisher: Addison Wesley Professional Pub Date: October 29, 2007 Print ISBN-10: 0-321-37446-0 Print ISBN-13: 978-0-321-37446-2 (Available on Safari.) --------------------------------------- When you store a pdb in the symbol server e.g.: prompt>symstore add /r /f C:\junk2\bin\*.* /s C:\symbolstore\ /t "MyApp" /v "Build 632" the symstore will create a directory structure which contains a GUID extracted from the PDB. As it turns out a PDB is given a GUID when it is created. One way to read the GUID is to use the dbh tool. e.g.: C:\junk2\bin>dbh -v srvind MySymbol.pdb Details on the dbh tool can be found in the MS Help files shipped with the "Debugging Tools for Windows". Note: Examples assume C:\Program Files\Debugging Tools for Windows (x86) is on your path. =============================================== Supporting Symbol/Source Servers in NMaven To properly support symbol and source server functionality in NMaven there appear to be two good choices I can see. These are: -------------- Option 1: a) Create a plugin(s) which downloads the pdb files of every dependency (saved in the mvn repo as attached artifacts) and executes symstore to save the pdb files in a local symbol store. b) Create a plugin(s) which downloads the source archives of every dependency (saved in the mvn repo as attached artifacts) and expands them into a directory structure matching that of a UNC store. (See "HTTP Sites and UNC Shares" section of srcsrv.doc.) c) Ensure the pdb files are properly processed to include the necessary source stream during or before the deploy phase. It is important SNAPSHOT artifacts include this information so one can't wait for the release plugin to do the job. -------------- Option 2: a) Same as Option 1.a b) Process the pdb files during/before the deploy phase to include the information necessary to extract a single source file. Under the covers the command line call formed when VS processed the source stream from the pdb file will need to resolve the relevant source archive and extract the relevant file from the source archive. The best way to do this is likely to work out a one line mvn call which will return the relevant source file, creating a plugin or two as necessary. The command line call formed when processing the source stream in the pdb file will therefore simply be a call into maven.
----------------- Note: Careful examination of the perl scripts included in C:\Program Files\Debugging Tools for Windows (x86)\srcsrv\ and documented in the associated MS Word document should be enough to understand how the pdb processing works in both Option 1 and 2. ----------------- Effort Estimate: Option 1 may be slightly easier to implement, but option 2 will probably be a tad more elegant. It wouldn't be that much more effort to support both. I would guess either approach will probably take a week or two of work to complete, including testing.
