views:

75

answers:

2

I have a project which is the core of our application. We build several DLLs and an EXE.

We then have custom projects which use pre-built core DLLs and EXE and add customisations/extra bits as required. These customisations are always DLLs, the core EXE is always used. The core DLLs/EXE are referenced by the custom solution.

I'm having a bit of a problem while debugging getting the custom DLLs to load. Because the EXE is pre-built we use one the projects as the startup project which points to the location of the EXE and the rest of the DLLs. However it then doesn't seem to the load the startup project DLLs.

How should I be setting my custom solution/projects up when the EXE is already built?

(NOTE: the custom DLLs provide components which are loaded reflectively from metadata if you're wondering)

UPDATE: Current approach is to have a post-build event in the "top-level" project of the custom solution which copies all the core DLLs and EXE into the bin/Debug directory. Then set that top level project as the startup project and point to the copied EXE in bin/Debug. It then finds the DLL because it is in the same directory as the EXE (along with all the others).

A: 

You can run the .exe, then attach Visual Studio Debugger to the process. Make sure the .pdb for your .dll is in the executing directory.

Yuriy Faktorovich
This is for development work on the custom solution so attaching the debugger would be prohibitively annoying. I just want to be able to click run/debug like I normally do and it start the .exe while loading the custom DLLs too.
Mike Q
@Mike You can write a quick Macro, so you press a button/shortcut and it attaches to the process.
Yuriy Faktorovich
+1  A: 

Selecting a DLL as the startup project does not in any way guarantee that it actually gets loaded. That EXE you are using has to use Assembly.Load/From() to get the DLL loaded. At that point does the debugger step in and activate the break-points you set.

Easy to tell from the Debug + Windows + Modules window. If you don't see your DLL loaded in that window then nothing is going to happen. You'll need to find out what the exact configuration rules are for that EXE so that it will load the DLL you want to debug.

Hans Passant
Thanks that is interesting, and you're right my DLL is not getting loaded. We've worked round it by having a post-build copy event that copies all the external libs into the /bin/Debug directory of the "main" DLL in the custom project, and then pointing the startup app to the copied version of the EXE. This works ok but seems a bit clumsy. Do I have any other options to allow the EXE to "discover" my additional DLLs at runtime other than putting everything in the same dir?
Mike Q
I know less about that EXE than you do. Having all the DLLs in one directory sounds pretty normal to me. Sure, copying them there in a post-build event is the usual approach. Or you could just change the DLL project's Output Path property. Project + Properties, Build tab.
Hans Passant
OK thanks. I can live with the post-build approach as it's a one time setup per project. I'm used to Java which seems to work smoother, probably because of the need for an explicit class path when debugging or otherwise.
Mike Q