Option 2b and option 1c both result in very little extra space in the PDB. In neither case does the PDB contain the source.
I haven't gotten my hands dirty yet, but basically there is just a little bit of meta-data inserted into the PDB for source server support in either case. This meta-data is just enough to teach the debugger (Visual Studio/etc.) how to acquire the source. I recommend the following approach to getting your head around this. 1) Install "Debugging Tools for Windows". Add the binaries to your PATH. 2) Insert a few random pdb files into the symbol server. (See example command from my original post.) Take a look at the structure created. 3) Skim the two online articles: http://msdn.microsoft.com/en-us/magazine/cc301459.aspx http://msdn.microsoft.com/en-us/magazine/cc163563.aspx 4) Carefully read the MS Word document, skimming the contents of the srcsrv directory and the associated perl modules as you do so. C:\Program Files\Debugging Tools for Windows (x86)\srcsrv\srcsrv.doc 5) Skim the relevant chapter in the book I mentioned if you have easy/inexpensive access to it. Otherwise, just skip it. 6) Briefly look at the symbol/source server section of the MS help which ships with "Debugging Tools for Windows". >Would the client end of this be easier to achieve if it were managed from >Visual Studio integration itself? I don't think so. Apparently, symbol and source server support as described by the referenced documents is the standard Microsoft approach to supporting this sort of functionality. Microsoft supplies several debuggers (command line and GUI) which all appear to be integrated with the symbol and source server mechanism described. Using another approach would be swimming upstream. I think you need the enterprise license of VS to get source server integration, but such is life. The only functionality a VS plugin might add would be the ability to easily browse sources associated with a project resource. Under the covers the plugin would still be using the symbol/source server support to get at the files. This sort of browsing is where option 1b might be useful. As I mentioned orginally, option 1 and 2 can probably peacefully coexist. The MS Word document sort of implies they could. My personal opinion is that Microsoft should enhance the resource reference mechanism in Visual Studio and msbuild to support a proper artifact repository. If MS supplied tools did for .NET what maven and maven IDE plugins do for Java, there would be no compelling reason to leave the MS camp. Companies would be best served by simply paying for Team Server and getting on with life. Currently, MS hasn't done any of this so integrating with the symbol and source server support as it exists today is the way to go. If MS does enhance things, I suspect they will do so by enhancing the existing symbol server support, source server support and VS integration with the same. --- On Tue, 9/23/08, Brett Porter <[EMAIL PROTECTED]> wrote: > From: Brett Porter <[EMAIL PROTECTED]> > Subject: Re: Research into Symbol and Source Servers > To: [email protected] > Date: Tuesday, September 23, 2008, 6:43 PM > Thanks for this James. I have some questions... > > On 24/09/2008, at 2:19 AM, James Carpenter wrote: > > > 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. > > Does option 2 (b) result in a larger PDB file than 1 (c)? > IIUC, you > are basically including the entire source in there, vs a > reference to > a source which would be stored elsewhere. > > If so, option 1 seems slightly more efficient from the > repository's > perspective (as having a source archive could make sense > regardless). > But it depends on how much complexity this adds on the > client side. > > Would the client end of this be easier to achieve if it > were managed > from Visual Studio integration itself? > > Thanks, > Brett > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/
