Debugging code from dynamically loaded assembly in .net core 2.0

Question

I have a .net core 2.0 console app that does the following (simplified):

var a = Assembly.Load(Assembly.GetEntryAssembly()
                              .GetReferencedAssemblies()
                              .First(i => i.Name == "MyAssembly"));

var t = a.GetType("MyType");
var i = (MyBaseType)Activator.CreateInstance(t);

i.Execute();

When I debug through the code it stepps into MyType.Execute() as expected.

However If I load the assembly with the following code:

var path = new FileInfo(Assembly.GetExecutingAssembly().Location);
var a = Assembly.LoadFile(Path.Combine(path.DirectoryName, "MyAssembly.dll"));

The code still works but I can't step into MyType.Execute() while debugging.

Any Idea why/what's wrong?

Answer 1

This may be caused by the application not being able to locate PDB file associated with MyAssembly assembly, as mentioned in one of the comments. However, it seems that the PDB file is not required in the same folder as the assembly to make debugging work.

In order to check if symbols are loaded, please put a breakpoint in the line just after calling Assembly.LoadFile() and open Modules window (it can be found in Debug\Windows menu in Visual Studio). In this window, find the MyAssembly assembly and verify value in Symbol Status column. If missing PDB is the cause, the value will be "Cannot find or open the PDB file.". You can also use that window to see where debugger tried to find the symbols file.

Debugger looks for the PDB files in several locations, as described here: Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger.

According to the article, the default locations for a PDB file are:

1. Location specified inside the assembly itself (placed there by a linker when the assembly is compiled)
2. Folder where the dynamically loaded assembly resides
3. Local symbol cache folders
4. Internet, network or local symbol servers

I suppose that in Your case, the first or the second location mentioned should be considered.

Another important thing to notice is that the PDB must exactly match the assembly, so after recompiling the assembly the PDB file should also be updated to match the new version.

If the PDB file matches the assembly and resides in one of the mentioned locations, You should be able to debug the code.

There may be other causes and this is not directly associated with the fact that .NET Core is used, but I suppose that correct PDB loading may be worth verifying.

Answer 2

Did you check option just my code?

Enable Just My Code

("My Code") only, ignoring system code and other code that is optimized or that does not have debugging symbols.The debugger displays and steps into user code

Maybe it should be unchecked?