# Visual Basic > Visual Basic .NET >  [RESOLVED] How Does VS Find Source Code

## Shaggy Hiker

I mentioned this feature in this thread from Funky:

https://www.vbforums.com/showthread....MEF&highlight=

VS has a near magical ability to figure out where the source code for a dll is, even when the dll is loaded dynamically from a location unrelated to the project where it was created, and even when there is no reference to the dll (which is what dynamic loading means, but I wanted to be clear about that). I'm wondering if anybody can explain how VS is doing this...because it has suddenly become important for the worst of reasons: For one project, it has stopped working at all.

I make extensive use of this feature, though I have never taken the time to figure out how VS is doing it. I create plugins for a project. The plugins are built in VS projects as class libraries. I then take the exe from either the Debug or Release folder (it does make some difference which I use, but not all that much) and copy it into a folder in the Users/Public Documents folder. This copying is a manual process that doesn't involve VS (though I did write a program that will do that for many projects at once, but that's irrelevant, as I wasn't using that program today). 

When I run the main program, it looks at each dll in the specified Public Documents folder, looks in each one for an object implementing a certain interface, and if it finds one, it creates an instance of that object. VS allows me to step into the constructor of the object, or any call to a member of the interface. This allows me to step through and debug the code, which is very useful. 

I thought this might have something to do with setting where source folders are located in VS, but I noticed today that I had never changed that. The location that VS was holding was the default it had when it was installed, even though NONE of the projects (the main project nor any of the plugins) was located in that default location. So, I have no idea where VS is going for the source files. Perhaps it is looking in sibling folders of the running project. If that is the case, then if the project is in folder Foo, then VS looks first in sibling folders to Foo, but that seems a bit unlikely for reasons I'll skip as this is already too long.

For all projects save one, this is working fine. For this one, nothing I can do seems to get VS to even try to find the source code. Having worked with this for the last 13 years, I have a bit of experience with this. If VS gets lost, it usually prompts me as to where the source location is found, then gets confused when I tell it. This has always been correctable by doing a total rebuild. That's not working this time. I've removed the bin and obj folders, changed code so that a rebuild really does do a rebuild, removed things, added them back in, and anything else I could think of. VS simply declares that it is <external code> and refuses to step into it.

So, while I'd take any suggestion as to how to study this further, what I'm really looking for is somebody who can explain a bit as to how VS is finding the source code in the first place, as that might help me figure out why it won't even try in this case?

----------


## Shaggy Hiker

The plugin that was having problems was always a conceptually foolish plugin. The issue was that there were three different concepts covered in the same dll, with perhaps 9-12 different plugins in the file. This was always a bad idea, but had lingered around since the dawn of the project because I hadn't bothered separating them into their different concerns. Because of this issue, I took the (brief) time required to split them out into three different problem domains. That was a help, as it narrowed the problem down. Two of the three are working just fine, while the new project that includes the third problem domain, is still having the same problem. So, at least I know where the problem is located.

This may be related to the other thread I currently have about user controls, because the plugin that has the user control that can't be shown in the designer (though it works) is the one that I can't debug. Arguing against that is the fact that I can remove that user control, rebuild the project, and STILL can't step into the source code for this plugin. 

The plugin file now has only three plugins in it. It would be super painful to try to separate it any further. It's currently in it's most logical organization and subdividing would be possible but undesirable.

----------


## Shaggy Hiker

Well, the question remains, though the problem that prompted it has been...solved. Unfortunately, I don't really know how it was solved, which is why the question remains.

What solved the problem was removing the FlickerPanel from the project and re-building. The problem went away, but since the FlickerPanel was important, I then went back and included it back into the project and rebuilt again. This time...the problem is still gone. So, removing and re-adding the FlickerPanel solved the problem. How it did so, I can't say. 

Therefore, I'm still curious as to whether or not anybody has any insight into how VS can find the right source (or any source) when all it has is a release compiled dll and the source does exist somewhere on the same computer, though not associated with the location where the dll is found?

----------


## OptionBase1

It might be possible to determine what VS is doing behind the scenes to traverse from a compiled and moved dll back to the original source project by running Process Monitor and capturing all events during the time that said "magic" happens and then digging through the  resulting events one by one to try to determine which ones are performing the "backtrace".

----------


## OptionBase1

Another possibility is that the path to the source project files is written into the dll file somewhere (should be able to check this with a hex editor), and VS does a check to see if that path exists on the system (and if it does I'm sure it does a GUID comparison and other checks to make sure it is the same project and version) and then jumps into the project that way.

Edit: Using Notepad, I opened a custom control I created in VS 2010, and the full path to the outputted obj\Debug\control.pdb file exists in plain text in the dll file, so that is almost certainly how VS is tracking down the original project.

----------


## Shaggy Hiker

Okay, that helps. I guess if the path to the file is found in the dll, then that explains how that magic is working. I checked with one of these dlls, and found the same thing. I didn't realize there would be simple readable text in a dll. Not much of it is readable, but that path is there.

So, that answers the question I asked here, but makes the mystery just a bit deeper. I'll close this thread and continue in the other thread I have.

----------

