When you say debug mode was activated, do you mean the build type specified in CMake, or the debug option inside Visual Studio?

Unfortunately, very few of the devs are using windows machines (and even fewer are using Visual Studio), so I can't come with any good suggestions.

If I recall correctly, the BUILD_TYPE in CMake isn't used for Visual Studio (since VS picks the build type later), so it makes no difference if you put in Debug in that field.
What I mean is the debug build setting inside VS. On the top bar, there should be a drop menu where one can select "Debug"
It's next to the Start option on in this screenshot
http://blogs.msdn.com/cfs-filesystemfil … a-Full.png

Under linux, some IDEs you can try are KDevelop, QT creator, and Eclipse CDT or Code::blocks

I believe you missed the attached figures (there are none that I can see)
If there are problems attaching them, you can use something like:
http://picpaste.com/
and paste the links.

I had the same (unexpected) problem in some VS installation and I solved using USE_LIB=OFF in CMake. Let me know if it helps you; VS will generate an EXE without the DLL file.

Exact CMake entry: USE_SHARED_LIB

Use Cmake to re-create the solution and the VS projects. In Cmake, deselect USE_SHARED_LIB and then Configure and Generate.

Hmm.
This is an ideal solution. The shared library is used for things like the python bindings, USE_SHARED_LIB=Off  limits this functionality. It's also in general the way you want to build OOFEM so that it can build multiple targets (like the standalone binary beam01 example)
The USE_SHARED_LIB was intended for a backwards compatibility mode, and it is something I would like to remove in the future.

If someone with Visual Studio can figure out if there is a change we can do to make VS automatically load symbols for the "oofem.dll", then it would be greatly appreciated.

Hello, I am experiencing the same issue as the one you are describing above (some years ago). I am using VisualStudio 2022 though.
The compile has been done successfully and I can run the examples in both debug and release mode (both by using the oofem.exe).

But when I am debugging and setting a breakpoint, the analysis doesn't stop to a breakpoint. I cannot check the process as I want in order to understand how the code works. Again, as you described above, I can set a breakpoint to the main.C and the analysis will stop at the breakpoint (so it recognizes the breakpoint). But when i am running an example like Mises01.in and I am setting breakpoints in misesmat.c, the analysis goes straight to the output.

Am i doing something wrong? (I deselected the USE_SHARED_LIB). Where should i put a breakpoint-in which module the code reads the data (in case the problem is that I am setting the breakpoint in a wrong location)?

thank you and sorry for the long message.

Thank you so much for the reply. I know that you are a linux guy-please bear with me :)

I don't see a liboofem project in the solution explorer (you may see a picture attached). This code that relates to liboofem (like dof.c) exists in core. I can do the changes you described, only to the startup project (which is only the oofem). So right-click in oofem->properties->linker->Debugging->Dubuggable Assembly-Yes

It didn't solve my problem. Am I missing something for the installation steps?

Just to clarify, I run an example like this:
In the terminal of Visual Studio (Developer PowerShell or Developer Command Prompt), I navigate to the path of the debug folder (where the oofem.exe has been created) and then I write:
.\oofem -f C:\Users\...\oofem\tests\sm\Mises01.in

This action immediately is analysed successfully ignoring that I have put breakpoints in misesmat.c