Quick guide to debugging extensions

[Robert Scheller]

Dear All:

Austen Ruzicka, rock-star LANDIS-II programmer, offers the attached guide to debugging extensions in LANDIS-II.  Thanks, Austen!

[Paul Schrum]

Hello everybody,

I will be working with Dr. Scheller this summer on doing some Landis-II-7 extension development.

I have worked through the Debug Guide 2018, which Dr. Scheller has posted above, and I am almost there in terms of getting it to stop at breakpoints, but I need a little help.

Working so far:

Here is what I have working so far. I am able to run a sample script that uses base-wind, and I have made a minor test change (the Console.ReadLine() statement recommended in the document).

The Problem:

My problem is that when I Attach to Process, it still can't find symbols, so it never stops at my debug point. (I set one right after the Console.ReadLine() statement recommeded in that doc.)

What I have tried so far:

1.On the base-wind Project on the Build side-tab, I have changed Output path to LANDIS-II-v7\extensions. But it will not put them there. It puts them in LANDIS-II-v7\extensions\netstandard2.0. But when I run the console command, it does not link to that dll; it links to the one above it, in extensions. So when I build it, I still have to copy the dll and the pdb up one directory before changes appear in a run. I don't mind doing this; it just does not solve my problem.

I also added the path to the Symbol file (.pdb) location (see Debug > Option > Debugging > Symbols). Yet this does not allow me to hit a breakpoint, and at this point I need some guidance.

Thanks in advance for anyone who can help me.

- Paul Schrum

Raleigh, NC

[Austen Ruzicka]

Paul,

Two things may be happening. The process you are attaching to is not the running LANDIS-II instance, and/or Visual Studio is having trouble reading the symbols.

The simplest way to set up the symbols for debugging is to build the project in debug configuration, go to bin/debug/netstandard2.0 then copy both the Base Wind .dll and .pdb file. Paste both of these in LANDIS-II-v7/extensions. LANDIS-II's configuration can be wonky so it is best to play it safe and put the symbols exactly where the program expects them to be.

If this does not work, you may not be attaching to the correct process. I note in the debug guide that dotnet.exe is the most likely process, but it can be known by a few other names depending on your computer. You may have to do some googling to find other common process names for .NET programs.

[Brian Miranda]

Paul,

One thing that might be tripping you up is that, by default, Visual Studio appends the name of the target framework (in this case netstandard2.0) to the output path.  But there is a way you can prevent that from happening, so that the .dll and .pdb files show up where you expect them to.

Within VS, right-click on the name of the project, and select "Edit projectName.csproj".  Then within the <PropertyGroup> section add this line:

<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>

This will prevent VS from adding the netstandard2.0 subfolder to the output path that you provide.  I don't know for sure that this will get you fully functioning with this debugging method, but it should resolve that one issue that you identified.

Cheers,

-Brian

[Paul Schrum]

Thank you Austen,

I was attaching to the wrong process. I finally found dotnet.exe, attached to that, and I am able to debug now.

Problem resolved.

- Paul

[Paul Schrum]

Thank you Brian,

That suggestion works perfectly. Also, it is something I never would have figured out.

- Paul