Debug DLLs in Visual Studio (C#, C++, Visual Basic, F#)

Artigo
04/18/2022

Applies to: Visual Studio Visual Studio for Mac

Note

This article applies to Visual Studio 2017. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here

A DLL (dynamic-link library) is a library that contains code and data that can be used by more than one app. You can use Visual Studio to create, build, configure, and debug DLLs.

Create a DLL

The following Visual Studio project templates can create DLLs:

C#, Visual Basic, or F# Class Library
C# or Visual Basic Windows Forms Control (WCF) Library
C++ Dynamic-Link Library (DLL)

For more information, see MFC debugging techniques.

Debugging a WCF Library is similar to debugging a Class Library. For details, see Windows Forms Controls.

You usually call a DLL from another project. When you debug the calling project, depending on the DLL configuration, you can step into and debug the DLL code.

DLL debug configuration

When you use a Visual Studio project template to create an app, Visual Studio automatically creates required settings for Debug and Release build configurations. You can change these settings if necessary. For more information, see the following articles:

Set C++ DebuggableAttribute

For the debugger to attach to a C++ DLL, the C++ code must emit DebuggableAttribute.

To set DebuggableAttribute:

Select the C++ DLL project in Solution Explorer and select the Properties icon, or right-click the project and select Properties.
In the Properties pane, under Linker > Debugging, select Yes (/ASSEMBLYDEBUG) for Debuggable Assembly.

For more information, see /ASSEMBLYDEBUG.

Set C/C++ DLL file locations

To debug an external DLL, a calling project must be able to find the DLL, its .pdb file, and any other files the DLL requires. You can create a custom build task to copy these files to your <project folder>\Debug output folder, or you can copy the files there manually.

For C/C++ projects, you can set header and LIB file locations in the project property pages, instead of copying them to the output folder.

To set C/C++ header and LIB file locations:

Select the C/C++ DLL project in Solution Explorer and select the Properties icon, or right-click the project and select Properties.
At the top of the Properties pane, under Configuration, select All Configurations.
Under C/C++ > General > Additional Include Directories, specify the folder that has header files.
Under Linker > General > Additional Libraries Directories, specify the folder that has LIB files.
Under Linker > Input > Additional Dependencies, specify the full path and filename for the LIB files.
Select OK.

For more information on C++ project settings, see Windows C++ property page reference.

Build a Debug version

Make sure to build a Debug version of the DLL before you start debugging. To debug a DLL, a calling app must be able to find its .pdb file and any other files the DLL requires.

You can create a custom build task to copy the DLL files to your <calling project folder>\Debug output folder, or you can copy the files there manually.

Make sure to call the DLL in its correct location. This may seem obvious, but if a calling app finds and loads a different copy of the DLL, the debugger will never hit the breakpoints you set.

Debug a DLL

You can't run a DLL directly. It must be called by an app, usually an .exe file. For more information, see Visual Studio projects - C++.

To debug a DLL, you can start debugging from the calling app, or debug from the DLL project by specifying its calling app. You can also use the debugger Immediate window to evaluate DLL functions or methods at design time, without using a calling app.

For more information, see First look at the debugger.

Start debugging from the calling app

The app that calls a DLL can be:

An app from a Visual Studio project in the same or a different solution from the DLL.
An existing app that is already deployed and running on a test or production computer.
Located on the web and accessed through a URL.
A web app with a web page that embeds the DLL.

To debug a DLL from a calling app, you can:

Open the project for the calling app, and start debugging by selecting Debug > Start Debugging or pressing F5.

or
Attach to an app that is already deployed and running on a test or production computer. Use this method for DLLs on websites or in web apps. For more information, see How to: Attach to a running process.

Before you start debugging the calling app, set a breakpoint in the DLL. See Using breakpoints. When the DLL breakpoint is hit, you can step through the code, observing the action at each line. For more information, see Navigate code in the debugger.

During debugging, you can use the Modules window to verify the DLLs and .exe files the app loads. To open the Modules window, while debugging, select Debug > Windows > Modules. For more information, see How to: Use the Modules window.

Use the Immediate window

You can use the Immediate window to evaluate DLL functions or methods at design time. The Immediate window plays the role of a calling app.

Note

You can use the Immediate window at design time with most project types. It's not supported for SQL, web projects, or script.

For example, to test a method named Test in class Class1:

With the DLL project open, open the Immediate window by selecting Debug > Windows > Immediate or pressing Ctrl+Alt+I.
Instantiate an object of type Class1 by typing the following C# code in the Immediate window and pressing Enter. This managed code works for C# and Visual Basic, with appropriate syntax changes:
```
Class1 obj = new Class1();
```
In C#, all names must be fully qualified. Any methods or variables must be in the current scope and context when the language service tries to evaluate the expression.
Assuming that Test takes one int parameter, evaluate Test using the Immediate window:
```
?obj.Test(10);
```
The result prints in the Immediate window.
You can continue to debug Test by placing a breakpoint inside it, and then evaluating the function again.

The breakpoint will be hit, and you can step through Test. After execution has left Test, the debugger will be back in design mode.

Mixed-mode debugging

You can write a calling app for a DLL in managed or native code. If your native app calls a managed DLL and you want to debug both, you can enable both the managed and native debuggers in the project properties. The exact process depends on whether you want to start debugging from the DLL project or the calling app project. For more information, see How to: Debug in mixed mode.

You can also debug a native DLL from a managed calling project. For more information, see How to debug managed and native code.

Partilhar via