I have a runtime written in C++ (with Mono embedded) which calls functions in a dll written in C# using mono_jit_exec and mono_runtime_invoke. The glue code is generated with CppSharp - which I don't think is relevant here, but just to mention.
So far all good, I can communicate in both directions.
What I want now is to debug the C# code only, using Visual Studio (I'm using the version 2019 on macOS). So in my C# project, I went to Run Configuration and selected the Start external program option pointing to my C++ assembly. After that, I've set some breakpoints, but when I run the C# project in Debug mode, they're never triggered.
Why is not working - is there something else that needs to be done? Is it because Mono is involved?
Ok, so the answer is that is currently not supported.
A workaround would be to do remote debugging using a plugin for Visual Studio or Visual Studio Code, as Unity does.
One available extension is VS Code Mono Debug, which is based on the SDB: Mono Soft Debugger Client.
Related
I am currently in the dilemma of trying to attach the debugger of Visual studio to a IronPython process.
I have a c# dll that i reference and use in a python scripts, via Ironpython (import clr).
In my c# program i call this python script, again via the IronPython setup.
C# Code to run Python Scripts and its class method
Steps I have done:
So far from the research done into this subject I have figured out that you need to add the options dictionary (as seen in the code) and also disable (Just my code) in the debug options. This should allow one to set a breakpoint in the python scripts which visual studio then can hit. Now this does not work for me in both vs 2019 / vs 2022. Only vs 2017 managed to hit these breakpoints. When I run it with debugger the breakpoints simply say
(The breakpoint will not currently be hit. No symbols have been loaded for this document)
Again from the research done it looks like the fault is that vs 2019 and 2022 do not support the python version that IronPython uses and as such I am slowly giving up on. The overall goal with my project is simply to try to make the debugger work.
Question:
Is there maybe still a way to attach visual studios debugger to a IronPython process and debug the .py file??
PS: I tried both ironPython 2.7 and 3.4.1 alpha
You could add the following code in your script:
import clr
import System
System.Diagnostics.Debugger.Break()
Then run your host .NET application under Visual Studio debugger, then run the script.
The script execution should stop in Visual Studio debugger, where you will be able to step, evaluate, etc.
Also note that IronPython supports standard python tracing mechanism (i.e. settrace). With this, you could implement a custom debugger/tracer for your scripts. For example, we made such an IronPython script debugger as a part of our product called AlterNET Studio.
I am developing a .NET core (.NET Standard 1.6) application in VS2015. The application calls C++ code via P/Invoke. Now I need to step into the C/C++ code of my native dll project.
In regular .NET application, by enabling unmanaged code debugging in the property window of the application, we can step into the C/C++ code directly:
But I can't find such option on a .NET core project. And I know that I can attach the debugger to the application to debug native code only, but that's not suitable for my case.
Again, I want to debug from managed C# code into native C/C++ code.
Any ideas?
Maybe I should switch back to .NET Framework so I can debug the native code. It's really hard to debug by printf. :(
UPDATE
The mixed mode debugging, i.e. debugging from managed C# code into native C/C++ code, has been implemented. See Tutorial: Debug managed and native code in Visual Studio.
UPDATE
The feature may have already been implemented, see this.
Just as #cynic said, this is not yet supported now (2016-11-1).
That can be verified by following steps provided by cynic.
Put a pause in your program (e.g. a Console.ReadKey call).
Attaching to the dotnet.exe process selecting "Managed (CoreCLR)" and "Native" code types
You'll get a message box stating explicitly that "Interop debugging is not supported".
Here is a proper way to debug the native dll.
Right click on the solution, Add Existing Project
Open 'dotnet.exe'. This is normally installed to 'C:\Program Files\dotnet\dotnet.exe'.
You should now see another node in solution explorer for dotnet.exe. Right click it to bring up project properties:
Change the working directory to be what you want
Change the arguments to be the path to your built dll
Change the exe project to your startup project
RECOMENDED: Go to Tools->Options->Projects and Solutions->Build and Run, uncheck 'Only build startup projects and dependcies on Run'
I am running VS Code on Ubuntu 14.04. I am trying to run a C# web application which my team can run just fine in Visual Studio on Windows. The problem is that Code gives me an error message, "/app.js does not exist". No such file exists in our project, and I think I want to run it using "Startup.cs" instead, but despite trying to change the 'launch.json' file accordingly, another file that my team does not have, I still cannot get my project to run. Has anyone experienced a similar problem?
The .NET environment for Linux is currently in a pretty early state. Thus you can't do everything on Linux that you can enjoy on Windows.
If you want to develop an ASP.NET application then you should read this guide on how to setup the environment to work with Visual Studio Code.
If you have a C# application that can already be compiled and run on Linux then you can
create a script file which compiles the project and runs it afterwards
and let this script be executed as the build task in Visual Studio Code. Here is how to do it: How to prepare/configure development environment for C++ projects in Visual Code Editor?
Just for your interest: You can't currently debug C# projects in Visual Studio Code.
Perhaps you can try to open the project with Monodevelop? This is an open source IDE for C# that runs on linux. It is compatible with VS projects.
You will probably need to also install Mono (the open source .net runtime) to run Monodevelop.
You may even be able to run your web app with the Mono runtime, although it has been always a bit behind the official Microsoft .net runtime (you may get 'class not found' exceptions if your code uses libraries that are not yet implemented in the Mono runtime).
I'm working on a three projects.
The first one is a native C++ dll, let's name it as a native.dll.
The second is a C++/CLI dll (man.dll), which contains a bunch of wrapper functions (native.dll is statically linked).
Finally, the man.dll is used( as a reference) in a C# WinForm project. Everything work perfect, I can use a native function in C#, but after a couple(!) builds (in debug mode) the C# project, I can't recompile native.dll, I can't even delete this file because Windows says that the file is being in use by Visual Studio.
Why?
I'm working in Visual Studio 2010.
Virus scanner can definately cause problems but in my experience they tend to be intermittent.
Have you tried the obvious things:
- restart visual studio?
- logout then back in?
- reboot?
Silly as it sounds in this day and age - sometimes it really can be that simple...
Python -> c++ dll -> c# dll
I have a com interop c# dll that is loaded in a wrapper c++ dll throught the .tlb file generated in c# to be used in a python project. When I run in my computer it works fine but when I run in a computer that just got formated it gives:
WindowsError: exception code 0xe0434f4d
I have the redistribute c++ installed and the .net compact framework 3.5 on the formatted computer.
How can I see what is the correct exception on a computer that does not have visual studio installed? How can I debug all of this? I can't debug the dll's itself can I?
Note: in my computer all works well so maybe is some dll or file missing. I allready used Dependency Walker to see if there's some dll missing, and nop!
Download the Microsoft Debugging Tools for Windows.
It contains the WinDbg debugger, which can also be used for debugging.
Advantage of WinDbg over Visual Studio is that you have much more low-level commands to find problems.
Disadvantage of WinDbg is that it's not that user friendly (compared to Visual Studio).
You can use WinDbg or other good applications to attach to the process or even run the application in the debugger application.
Another really good software is OllyDbg.
Both of these will both allow you to set breakpoints on different locations in your application.