none
Visual Studio 2015 Debugging Custom Control

    Question

  • I have custom controls compiled as DLLs that were developed with Visual Studio 2012 and are deployed to a production environment with no issues. These controls are loaded as "plugins" using reflection when the application loads.

    When I open the solution(s) with Visual Studio 2015 and attempt to set a break point, the break point states that symbols are loaded but it will never break when that section of code is hit.

    In Visual Studio 2012 these break points break correctly. I have tried to recompile the DLLs in Visual Studio 2015 and they still will not break. All PDBs are with the DLLs as well. Any ideas on what causes this?

    I have went though all the debugging settings in VS and have uninstalled / reinstalled VS and still have the same issue. I also know this breakpoint would be hit, it is in the initializer of the control right on InitializeComponent() method call.
    Tuesday, March 15, 2016 2:21 PM

Answers

  • If VS isn't identifying the PDBs as valid then one of several things are likely wrong:

    1. The loaded PDB doesn't match the loaded DLL. This can occur if the PDB is inadvertently getting picked up from a location other than what you expected.  Using the Modules window look at the DLL and PDB that were loaded and ensure they are in the same location and what you expected. This might be particularly appropriate if you're dynamically loading the assembly using reflection and the assembly doesn't reside in the standard search path.
    2. The PDB actually contains the full path to the source code embedded in it. When you set a breakpoint in your code (assuming you don't actually have the corresponding project loaded) then ultimately the debugger will try to map it to the PDB. But it really only cares about the filename itself. Hence if you built your code using C:\Builds\App\main.cs but on your local machine the path is actually C:\Projects\App\main.cs, provided you open the main.cs the debugger won't care. 
    3. When you set a BP outside of a debugging session it shows active. But as soon as you start debugging it goes inactive.  It won't return to active until the binary is actually loaded.  Since .NET uses deferred loading this may be a while.  Hence a BP that is inactive doesn't necessarily mean it is wrong.  Using Modules will help verify that binary has been loaded. If you're using reflection then it won't get loaded until that code runs.
    4. You mentioned that you use reflection. I assume you mean LoadFile or Load?  If you're using one of the other variants you may run into issues but that wouldn't have changed between VS2012 and VS2015 that I'm aware of.

    I'd be curious to know if debugging other DLLs in the same solution works OK. I'd also be curious to know if the assembly in question works if you try to load it as a regularly referenced assembly in a temp project just to confirm the PDB is valid.

    Wednesday, March 16, 2016 2:00 PM

All replies

  • That would seem to indicate that VS doesn't believe the PDB matches the DLL. It could also be an issue with optimized code. Try going to Tools\Options -> Debugging\General and ensure Just My Code is turned off and Require source files to exactly match the original version is off. In general I find that setting breakpoints directly in the source files when I know the PDB is correct, is loaded by VS and debug configuration was built then VS will hit the BP.

    Michael Taylor
    http://www.michaeltaylorp3.net

    Tuesday, March 15, 2016 5:47 PM
  • I changed those settings and it still doesn't hit the breakpoint. According to VS it has loaded the PDB and knows the breakpoint is valid.
    Wednesday, March 16, 2016 11:58 AM
  • If VS isn't identifying the PDBs as valid then one of several things are likely wrong:

    1. The loaded PDB doesn't match the loaded DLL. This can occur if the PDB is inadvertently getting picked up from a location other than what you expected.  Using the Modules window look at the DLL and PDB that were loaded and ensure they are in the same location and what you expected. This might be particularly appropriate if you're dynamically loading the assembly using reflection and the assembly doesn't reside in the standard search path.
    2. The PDB actually contains the full path to the source code embedded in it. When you set a breakpoint in your code (assuming you don't actually have the corresponding project loaded) then ultimately the debugger will try to map it to the PDB. But it really only cares about the filename itself. Hence if you built your code using C:\Builds\App\main.cs but on your local machine the path is actually C:\Projects\App\main.cs, provided you open the main.cs the debugger won't care. 
    3. When you set a BP outside of a debugging session it shows active. But as soon as you start debugging it goes inactive.  It won't return to active until the binary is actually loaded.  Since .NET uses deferred loading this may be a while.  Hence a BP that is inactive doesn't necessarily mean it is wrong.  Using Modules will help verify that binary has been loaded. If you're using reflection then it won't get loaded until that code runs.
    4. You mentioned that you use reflection. I assume you mean LoadFile or Load?  If you're using one of the other variants you may run into issues but that wouldn't have changed between VS2012 and VS2015 that I'm aware of.

    I'd be curious to know if debugging other DLLs in the same solution works OK. I'd also be curious to know if the assembly in question works if you try to load it as a regularly referenced assembly in a temp project just to confirm the PDB is valid.

    Wednesday, March 16, 2016 2:00 PM