Characters loaded into a C # C mixed project (win32) using VS2010

Question

In my project, several new C # modules and one C module (not C ++) compiled using win32 system calls. I use the PInvoke interaction layer to invoke C code from C #. Function C is called.

All modules write to one bin directory and write all pdb files.

When starting and stopping at a breakpoint just before the call to C.dll, I see that the breakpoints in the C module are disabled. Looking At Debug List | Windows | Modules I do not see the C.dll module loading even after the call has been completed.

Another fact: in the solution | Properties | Configuration Properties | Configuration shows C # modules using Platform = "Any processor" and C-module using "Win32"

Why is the module not loaded and why its symbols are not loading?

Thanks Max

Answer 1

I have summarized answers from several sources.

• Are you using a debug configuration?
  In the solution: SolnExplorer | Solution | Properties | Configuration | Properties | Configuration = Debugging
  and: SolnExplorer | Solution | Properties | ConfigurationProperties | Configuration | ProjectConfig [] = Debug -> Note. Although breakpoints will work with release configurations, sometimes lines can be optimized or reordered.

• Do you generate debugging information? In C # projects: SolnExplorer | Project | Properties | ConfigurationProperties | Linker | Debugging | Creating Debug Information = YES
  In C ++ projects: SolnExplorer | Project | Properties | ConfigurationProperties | C / C ++ | Debugging Information Format = Program Database (/ Zi)
  -> Note. Pays to check command line arguments.

• Is everything being rebuilt? If the PDB is not synchronized, the debugger may not be able to load characters:
  In the solution: SolnExplorer | Solution | Properties | Configuration Properties | Build = TRUE (checked) for all projects.

• Can you debug unmanaged code?
  In C # projects: SolnExplorer | Project | Properties | Debug | Enable Unmanaged Code Debugging = TRUE (Checked)
  In C / C ++ projects: SolnExplorer | Properties | Configuration Properties | Debugging | Debugger Type = Mixed

• Will the files be placed where you think? I use one bin \ debug directory to collect all project DLLs and PDBs.
  In C # projects: SolnExplorer | Project | Properties | Build | Output path = .. \ bin \ debug
  In C / C ++ projects: SolnExplorer | Project | Properties | ConfigProp | Linker | OutputFile = .. \ bin \ debug \ $ (TargetName) $ (TargetExt)

• Do old files interfere? Check the timestamps on all output files in the bin directory. Make sure they refer to the latest rebuild.
  Some people advise blowing away all bin and obj directories. This can only be useful to see that old files are not being laid. Checking the time and date markings should be the same.

• Is the DLL loaded? If breakpoints are disabled, this may be because the DLL is not yet loaded. Check menu | Debugging | Windows Modules |
  Locate the DLL in the module name.
  In the same "Modules" window, make sure that the files are downloaded from the correct path.
  If the assembly is distributed between several programs, it can be downloaded from the GAC.
  -> Note. You can preload the C / C ++ DLL before you need it. Usage: IntPtr lpDLL = LoadLibrary (myLibraryName);

Answer 2

I have a windows service in c # with c ++ dll. The problem I saw is what Max noticed:

• The DLL worked, but never appeared in the Modules window.

I have searched many times, and this is a good list that matches information from many other sources.

To make ich note noticeable:

• Auto didn’t work for me, but I explicitly set the Native and Managed code in the Attach dialog box.

Answer 3

Here are my fifty cents. In my case, it turned out that the pdb files of my C ++ / cli projects were no longer updated, and the pdb files of my C # projects. This probably made them invalid and caused the debugger not to load them.

I remembered that I had translated the source base of my project. After a bit of grepping, it occurred to me that a problem with an absolute path could be a problem. Running git clean -dfx solved the problem for me.