0

I have a mixed language class library used for numerical modeling. It is C# calling a native DLL that is created using C++ wrapping Fortran libraries. My solution contains a unit testing project, from which I can debug from the C# into the C++ and Fortran. I have a specific unit test that compares modeling results with different class library. This second library has C# calling Fortran directly. It is this second library that is giving me a problem. I have been able to compile most of the DLLs for this second library in debug mode using "Enable native code debugging" for the C# projects. I have also enabled "Just my code" to avoid debugging through Microsoft code. I can step from my unit test into the C# layer of the second library. When I get to the only Fortran call, my step into just steps over. After the step over, but not before, I can see the Fortran DLL I am trying to step into in the modules window. It is listed as user code and the pdb file is correctly referenced. I have forced the debugger to run the Fortran a second time, but it still will not step in. I have run out of ideas on what to check to get the debugging to work.

I have not included the projects from the second library into my solution. I am just pulling the compiled DLLs from a directory.

I am using VS2019 16.11.18 and Intel Fortran 2019.6.324

Edit: Some details.

I have not included the code from the second library in my solution because it uses Fortran source which has been modified from my original source and is incompatible. The team that modified it did not consider compatibility with other users and applications.

Update 6/13/2023:

I took the code from my unit test and created a simple application. It has a run button, so I can start the program separately from running the numerics, and a console to monitor output. I have tried starting the program and then using debug -> attach from the class library. I can then run the calculation and see the debugger step though the C# in the library, but it won't step into the Fortran. I did put break points in the Fortran. When I mouse over them, it says that symbols are not loaded. It is debug mode and debug native code is enabled.

spainchaud
  • 365
  • 3
  • 12
  • Can you debug Fortran only code? – Eljay Jun 11 '23 at 22:13
  • Can you set a breakpoint in your Fortran code? And, if so, does the debugger hit it? – Paul Sanders Jun 11 '23 at 22:59
  • I just tested a Fortran only project and I was able to debug. I have tried setting a breakpoint in the Fortran before compiling it into a DLL. I did not expect it to work, and it didn't. – spainchaud Jun 11 '23 at 23:01
  • What do you have set for `debugger type` in your project's properties? Make sure you're looking at the right platform and configuration! – Paul Sanders Jun 11 '23 at 23:06
  • All platforms are x64. The debugger setup in my Fortran, which I can debug, is the same as the setup in the external Fortran library. – spainchaud Jun 11 '23 at 23:21
  • *I have tried setting a breakpoint in the Fortran before compiling it into a DLL* -- *I did not expect it to work, and it didn't* -- How about attaching to the running process in the "Debug" menu? You have a choice of starting the process using the debugger (is this what you did?), or not start it, but start it "externally", and then attach to the running process (which is what I am suggesting). – PaulMcKenzie Jun 11 '23 at 23:25
  • Also [this answer](https://stackoverflow.com/questions/27154325/how-to-debug-a-windows-dll-used-inside-python/27154618#27154618), even though it talks about python, maybe relevant. – PaulMcKenzie Jun 11 '23 at 23:28
  • @PaulMcKenzie, I am not clear on how that is done. I start my unit test by right-clicking on the test method and selecting debug unit test. The test will pause at a debug point. If I then go to the solution containing my DLL and select debug -> Attach to process, I can find and select the process. I get a message that a debug process is already attached. If I just run the unit test, it will terminate before I can go through the steps to attach to the process. I do not understand how I would start my unit test externally. – spainchaud Jun 12 '23 at 10:57
  • Then you have to figure out what is the external command to start the test, and enter that in the `Configuration Properties -> Debugging -> Command` and `Command Arguments` on the DLL project. I am sure that tests should be able to run without an IDE -- what if these tests had to be automated? I am almost 100% sure this alternate method, if you can't attach to the process, will work. This is the defacto way to debug a DLL that is being used by some application, no matter what that application does or what language the app was programmed in. – PaulMcKenzie Jun 12 '23 at 12:59

1 Answers1

0

I finally came up with a resolution. Instead of running a unit test from my library solution, I created a unit test project in the solution containing the DLLs I needed to debug. In addition to the unit test, I had to move 42 classes from my library into the new unit test project. Once I had the unit test building correctly, I found that I had to hand copy 3 Intel Fortran DLLs into the folder where the unit test was running, each time I ran it. The final piece of the puzzle was that I had to run Visual Studio in admin mode. This is not something I had to do when debugging into native code in my own solution. I do not know why admin mode is required.

spainchaud
  • 365
  • 3
  • 12