There is a third-party program written in C #. One executable and a bunch of DLLs. One of them has to add code. I decompiled the necessary DLL, assembled it in debug mode. In the settings I registered the launch of an external program, the same executable module, copied the debugging DLL, just in case, into the working directory of the program. I start debugging, and Visual tells me, they say, you launched the release version for debugging. And I did not collect the release at all. No one will tell where I could get fucked? I’ll say right away that the last time the DLL wrote and debugged in the last century, and Sharpova, of course, was the first time.

  • Well, as if everything is OK, you are debugging a release exe-nickname, which tightens the debug dll. Studio curses, but it will debug. - PashaPash ♦
  • At the start, she breaks all dyuiblit. This is normal? - Hermann Zheboldov
  • It is worth looking at the window of the modules, looking at where the dll is pulled out from there, whether pdb was loaded. If not - upload - PashaPash ♦

1 answer 1

The dll file compiled by the studio must match the one that was loaded by the process. The difficulty is that when you start debugging, the studio can quietly rebuild the dll, and magic will not happen.

There are four solutions.

  1. Register in the project settings automatic copying of the library to the folder with an external program (there may be problems with teamwork, because the build settings are common to all)

  2. On the contrary, copy the external program to the output folder of the library

  3. Do not run debugging through the studio, but run the external process yourself, after which you "cling" to it while working.

  4. Same as in p.3 - but to put the Debugger.Launch() call in the right place of the library so that the library itself connects the debugger.

Another possible problem is that a foreign program can load the library not in the main, but in a child process. In this case, only options 3 or 4 will help.