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.

Answer 1

Make sure that optimization is disabled for DLL project, PDB generation is not none and build path is same from where the DLL is being consumed by other project. Many times just Cleaning whole solution, deleting Obj folder PDBs/dlls and rebuilding solves the problem.

Answer 2

Ways to Debug the DLL

Each of the projects in this section creates a DLL. You cannot run a DLL directly; it must be called by an application, usually an EXE. For more information, see Creating and Managing Visual C++ Projects. The calling application might fit any one of the following criteria: An application built in another project in the same Visual Studio solution that contains the class library. An existing application already deployed on a test or production computer. Located on the Web and accessed through a URL. A Web application that contains a Web page which embeds the DLL.

Debugging the Calling Application

To debug a DLL, start by debugging the calling application, typically either an EXE or a Web application. There are several ways to debug it. If you have a project for the calling application, you can open that project and start execution from the Debug menu. For more information, see b0fe0ce5-900e-421f-a4c6-aa44ddae453c. If the calling application is an existing program already deployed on a test or production computer and is already running you can attach to it. Use this method if the DLL is a control hosted by Internet Explorer, or a control on a Web page. For more information, see 636d0a52-4bfd-48d2-89ad-d7b9ca4dc4f4. You can debug it from the DLL project. For more information, see How to: Debug from a DLL Project. You can debug it from the Visual Studio Immediate window. In this case, the Immediate window plays the role of the application. Before you start debugging the calling application, you will usually want to set a breakpoint in the class library. For more information, see fe4eedc1-71aa-4928-962f-0912c334d583. When the breakpoint is hit, you can step through the code, observing the action at each line, until you isolate the problem. For more information, see 8791dac9-64d1-4bb9-b59e-8d59af1833f9.

Controls on a Web Page

To debug a Web page control, create an ASP.NET page that embeds it if such a page does not already exist. You then place breakpoints in the Web page code as well as the control code. You then invoke the Web page from Visual Studio. Before you start debugging the calling application, you will usually want to set a breakpoint in the DLL. When the breakpoint is hit, you can step through the code, observing the action at each line, until you isolate the problem. For more information, see FE4EEDC1-71AA-4928-962F-0912C334D583.

The Immediate Window

You can evaluate functions or methods in the DLL without having a calling application. You do design-time debugging and you use the Immediate window. To debug in this manner, do the follow these steps while the DLL project is open: Open the Debugger Immediate window. To test a method named Test in class Class1, instantiate an object of type Class1 by typing the following C# code in the Immediate window. This managed code works for Visual Basic and C++, with appropriate syntax changes:

Class1 obj = new Class1();

In C#, all names must be fully qualified. In addition, any methods or variables must be in the current scope and context of the debugging session. Assuming that Test takes one int parameter, evaluate Test using the Immediate window:

?obj.Test(10)

The result will be printed in the Immediate window. You can continue to debug Test by placing a breakpoint inside it and then evaluating the function again:

?obj.Test(10);

The breakpoint will be hit and you will be able to step through Test. After execution has left Test, the Debugger will be back in Design mode.

For more information please visit Debugging DLL Projects.

Answer 3

1) Try adding this tag

< loadFromRemoteSources enabled="true" />

inside the < runtime > tag on your config file.

2) Clean your solution.

3) On Solution > Properties > Project Dependencies > select the checkboxes from the "DLLs" projects and leave the "exe" project as startup project.

4) Build the solution, if the dlls are in a different project build that project first, then build the ".exe" one.

5) If this does not work, try to setup a different .net framework to your solution (to clean up the config file), then setup the original .net framework, and finally try steps 1, 2, 3 and 4 again.

Answer 4

Its probably that the symbols are not being loaded.

When you are attached to your program and you are sure your "plugin" has been loaded Select Debug -> Windows -> Modules.

Find your dll in the list and have a look at the "Symbol Status" column. It probably says "Cannot find or open the PDB file" or "Symbols not loaded".

Usually right clicking and selecting "Load Symbols" resolves this issue.

It will either load the file automatically or ask you to find the pdb manually.