Edit

Share via


Debug from a DLL project in Visual Studio (C#, C++, Visual Basic, F#)

One way to debug a DLL project is to specify the calling app in the DLL project properties. This approach lets you start debugging from the DLL project itself. For this method to work, the app must call the same DLL in the same location as the one you configure. If the app finds and loads a different version of the DLL, that version doesn't contain your breakpoints. For other methods of debugging DLLs, see Debugging DLL projects.

If your managed app calls a native DLL, or your native app calls a managed DLL, you can debug both the DLL and the calling app. For more information, see How to: Debug in mixed mode.

Native and managed DLL projects have different settings to specify calling apps.

Specify a calling app in a native DLL project

  1. In Solution Explorer, right-click the C++ DLL project and select Properties (Alt+Enter).

  2. In the <Project> Property Pages dialog, set the Configuration field at the top to Debug.

  3. Select Configuration Properties > Debugging.

  4. Expand the Debugger to launch list and select Local Windows Debugger or Remote Windows Debugger.

  5. In the Command or Remote Command box, add the fully qualified path and filename of the calling app, such as an .exe file.

    Screenshot of the Debug Properties window in Visual Studio showing the value for the command.

  6. Add any necessary program arguments to the Command Arguments box.

  7. Select OK.

Specify a calling app in a managed DLL project (.NET Core, .NET 5+)

  1. In Solution Explorer, right-click the C# or Visual Basic DLL project and select Properties (Alt+Enter).

  2. In the Debug tab, select Open Debug launch profiles UI.

  3. In the Launch Profiles dialog, select the Create a new profile icon, and select Executable.

    Screenshot of the UI to create a new debug profile in Visual Studio 2022.

  4. In the new profile, under Executable, browse to the location of the executable (.exe file) and select it.

  5. In the Launch Profiles dialog, note the name of the default profile, then select the profile and delete it.

  6. Rename the new profile to the same name as the default profile.

    An alternate approach is to manually edit the launchSettings.json file. You want the first profile in the launchSettings.json file to match the name of the Class Library, and you want the profile listed first in the file.

Specify a calling app in a managed DLL project (.NET Framework)

  1. In Solution Explorer, right-click the C# or Visual Basic DLL project and select Properties (Alt+Enter).

  2. Set the Configuration field at the top to Debug.

  3. Under Start action:

    • For .NET Framework DLLs, select Start external program, and add the fully qualified path and name of the calling app.

    • Or, select Start browser with URL and enter the URL of a local ASP.NET app.

    • For .NET Core DLLs in Visual Basic, the Debug Properties page is different. Expand the Launch dropdown and select Executable, and then add the fully qualified path and name of the calling app in the Executable field.
    • For .NET Core DLLs, the Debug Properties page is different. Expand the Launch dropdown and select Executable, and then add the fully qualified path and name of the calling app in the Executable field.
  4. Add any necessary command-line arguments in the Command line arguments or Application arguments field.

    Screenshot of the C# Debug Properties window in Visual Studio.

  5. To save your changes, select File > Save Selected Items (Ctrl+S).

Debug from the DLL project

  1. Set breakpoints in the DLL project.

  2. Right-click the DLL project and select Set as Startup Project.

  3. Set the Solutions Configuration field at the top to Debug. Select F5 and then select the green Start arrow, or select Debug > Start Debugging.

Tip

  • If debugging doesn't hit your breakpoints, make sure your DLL output (by default, the <project>\Debug folder) is the target call location for the calling app.

  • If you want to break into code in a managed calling app from a native DLL, or vice versa, enable mixed mode debugging.

  • In some scenarios, you might need to instruct the debugger where to find the source code. For more information, see Use the No Symbols Loaded/No Source Loaded pages.