3

I'm trying to re-jig the layout of a very large solution which has become impossibly hard (and s l o w) to work with. My plan is to create a number of solutions containing related projects, and then use binary references where necessary to link to libraries produced by the other solutions.

The thing we rely on to make this usable is Resharper's Navigate to External Sources functionality, so we can easily browse the source of the projects we are referencing from other solutions. Quite why VS can't do this out of the box is beyond me.

This is all working very nicely for classes with implementation. However, for C# interfaces and classes containing only auto-implemented properties, Resharper isn't able to browse to the sources, and falls back to cruddy metadata viewer.

I used srctool.exe, which comes with the Symbol Server tools in MS Debugging Tools For Windows, to browse the sources listed in the .pdb file, and it's clear that the sources for these interfaces and empty(ish) classes are not referenced in the pdb file. If I switch the auto-implemented properties to those with backing fields, then the source link appears in the pdb.

I'm guessing the sources are excluded because there are no places you could set breakpoints on interfaces and auto-implemented properties.

I'm wondering, though, if there is some exotic compiler option or workaround we can employ to force the PDB file to include references to the source of C# interfaces.

Thanks, Mark

Mark
  • 1,784
  • 16
  • 26
  • 1
    Please Note: If your answer contains words like "IoC" "DI Container" or cabbages, then I don't want to hear it. :) – Mark Nov 17 '11 at 10:56
  • Can you try verify the same behavior for .NET 2/3.5? – leppie Nov 17 '11 at 11:04
  • @Mark out of interest what command did you use to browse the sources in the pdb with srctool.exe?, srctool your.pdb -r ? – wal Nov 17 '11 at 12:52
  • @Mark that is a top question, I can only suggest asking Steve Johnson (of sosex fame) who should be able to give you an idea what is possible. check out http://www.stevestechspot.com/ – wal Nov 17 '11 at 13:02
  • @wal Yes, `srctool -r` is the command. – Mark Nov 17 '11 at 13:56
  • Etiquette question: Would it be wrong to answer my own question and collect someone else's bounty. I'm thinking: Yes, it would be wrong – Mark Jul 23 '14 at 10:35

1 Answers1

1

The question doesn't have enough detail. Shooting off the hip, I'd guess that you tackled the problems with the slow massive solution by converting project references to assembly references. And used the Release build of those projects as the reference.

And yes, that stumps any tool that tries to find source code files from the PDB. The release build of a .NET project uses a stripped version of the PDB, all the source code file and line number info has been removed from it. That's a pretty normal thing to do with real release builds. Release built code normally is optimized. That causes code to be re-ordered, no longer matching the logical position of the code in the source file. Any info you get from the source+line PDB info now tends to get between harmful and useless, you start looking in the wrong place for a problem.

That is however not a concern for IDE tooling or while debugging your app. The optimizer is automatically disabled in a case like this. Actually a configuration item in VS: Tools + Options, Debugging, General, "Suppress JIT optimization on module load" option. Turned on by default.

Clearly any tooling that uses the PDB is going to catatonic when they don't have a chance to find source files. The fix is to go back to the original project, select the Release configuration again and change a setting: Project + Properties, Build tab, scroll down, Advanced button. Change the "Debug info" combo from "pdb-only" to "full". Rebuild the project.

Should fix your problem. Also revives the debugger, you can step into the source code again.

Don't move files around too much btw, you might stump the chumps again. At least keep the PDB with the DLL in the same directory. If the source code is no longer present in the same directory but you checked it out again in another one then you have to tell the IDE about it. Right-click the solution, Properties, Debug Source Files setting.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Seems, you misunderstood the question. For me it sounds like "How to write interface source information into PDB?". For example, I wasn't able to find any source references for `ISession` interface in NHibernate's PDB file -- the same problem concerns all interface types from NHibernate. – ajukraine Jul 16 '14 at 15:05
  • Well, it wasn't your question so I had no hints that this had anything to do at all with NHibernate. It still applies, NHibernate would certainly be built the way I described, you get the Release build with a stripped PDB. It is Open Source so fixing it the way I documented isn't exactly a problem. – Hans Passant Jul 16 '14 at 15:34
  • But the PDB (for example, the one for NHibernate) contains full info about classes and it has no info about interfaces. That's the point of the question. – ajukraine Jul 16 '14 at 15:49
  • Well, the mystery tool you use probably only deals with classes that have code. Interfaces don't have any. Ping the tool vendor about it. Although he'd probably tell you that the auto-generated declaration you'd get from Visual Studio's "Go to Definition" command is already indistinguishable from the original declaration so should work just fine. – Hans Passant Jul 16 '14 at 16:02
  • The 'mystery tool' is C# compiler (the same, which used in Visual Studio)... I thought, you can provide a help concerning whether PDB file, generated by C# compiler, contains any symbol information from `interface` declarations... Is it possible to record interface's source information into PDB file using VS C# compiler? – ajukraine Jul 22 '14 at 15:12
  • Hard to make sense of this, the C# compiler is not involved in any of this. The Visual Studio IDE doesn't depend on the PDB file since it usually missing or out-of-date until the project is built. Using Go to Definition gives you a decent rendering of the interface as retrieved from the metadata of a reference assembly. – Hans Passant Jul 22 '14 at 16:57
  • http://msdn.microsoft.com/en-us/library/ms228625.aspx The MSDN says, that C# compiler generates .PDB files. – ajukraine Jul 22 '14 at 17:53
  • 1
    My problem was nothing to do with release mode. As it happens, I was using Debug mode builds, but release mode builds also have PDB references in them, so do not "stump" the IDE at all. The IDE tooling could find the source files for most things, but not simple classes with no explicit implementation. The Metadata viewer can re-construct the source more or less, but you will lose the code comments (excluding the /// comments, if you have the assembly metadata xml), and also the ability to edit the source file. – Mark Jul 23 '14 at 10:29