visual studio .net debugging: Here's some background information.

I have two C#.NET projects, one called IntegrationObj and one called
IntegrationBase.

IntegrationObj is a class library project that will dynamically call
other class libraries. (i.e. functionality inside allows a function
such as callSomeMethodInDLL(string className, string methodName, object
[] params, string dllName, etc...) )

IntegrationBase is my "dummy" class for this proof of concept. I am
dynamically calling methods from inside IntegrationObj that are within
the IntegrationBase dll.

The requirements of our platform are that I register these as COM
objects (using RegAsm filePath /codebase) so that it can integrate with
legacy code. ~sigh~ We're going to completely using .NET soon, but not
soon enough. Anyway, I'm trying to debug a method inside of
IntegrationBase as it gets dynamically called by IntegrationObj. I can
step through IntegrationObj just fine, but when I invoke a method in
IntegrationBase (pressing F11 to step into it), it skips over like I
pressed F10.

Both projects are set up for debugging. As I said, it's COM, so I'm
attaching to dllhost.exe and catching breakpoints in IntegrationObj as
they occur and trip my breakpoints. My modules window in .NET
(Ctrl-Alt-U) says "No symbols loaded" for IntegrationBase, but "symbols
loaded successfully" for IntegrationObj. Why? I even right clicked
IntegrationBase, chose "Reload Symbols..." and pointed it at the very
..pdb file generated by that project and it won't take it! Grr..

Any ideas? Both projects are set to DEBUG; TRACE;. Perhaps part of
the problem is that IntegrationObj.dll is the only .dll that gets
loaded by our platform, but IntegrationObj is the one making the
request for IntegrationBase, thus somehow causing symbols to not be
loaded. Any help would be appreciated. Thanks,

-Jeff

[quoted text, click to view]

It means that the DLL loaded by the process is not the same the PDB file
was created for.

It can happen if the DLL is loaded from unexpected location, e.g. an older version
left somewhere (check the path in Modules window in the debugger).

Another typical case is when the DLL is built in one location, copied to another
location where it can be found by the client, but the PDB file is not copied with it
and gets updated accidentally when the DLL in original location is rebuilt.
The solution is to always copy the PDB file together with the DLL.

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]

I'm glad you mentioned that about the .dll getting loaded from a
different location. I noticed that my IntegrationBase class didn't
have a complete path ("C:\Program
Files\blah-blah-blah\IntegrationBase.dll"). Instead, it has
"IntegrationBase.dll". No path. Does that mean it's cached or
something? How can I specify where to load it from. I ran RegAsm on
it once manually. Do I need to undo that? Thanks for the help! Or,
if you don't feel like answering all those questions, could I just read
about the paths for modules somewhere in the VS.NET documentation or
whitepapers?

Author note: Ok, I found my problem. I used Tools -> OLE/COM Object
Viewer in Visual Studio .NET to discover that I had 4-5 different .dlls
registered for my IntegrationBase.dll! Needless to say, .NET was
loading one of the .dlls I had copied somewhere w/ no .pdb and couldn't
load the symbols because it was a different version (in
AssemblyInfo.cs, you can set the version number to auto-increment. Go
set yours to a constant if you want to avoid this). So, I used regedit
(might be a better way, but this works) to remove all references to
IntegrationBase.dll. Using the OLE/COM viewer, you can get the CLSID
of the .dll and search for that in regedit. There will be an entry
under the folder(s) AppID and/or CLSID. Deleting the folder under
these that has the same name as your CLSID will un-register your .dll.
This is quite the hack. There's probably some tool somewhere that
removes it for you, but I searched and oculdn't find it...unless you
want to use RegAsm.exe DLLNameAndPath.dll /unregister. Anyway, once I
made sure I only had one entry for each of my .dll files (and that they
were pointed at what my .NET IDE was compiling in the respective /bin
directories), everything was dandy! I was able to debug breakpoints in
both classes. Thanks for the help guys!