I am talking about a small game engine using C# for game programming.
So, I have a C++ app embedding mono runtime (I call it 'launcher'). And I have an assembly written in C# which is my game engine class library. The launcher launches the assembly as it is suggested in Embedding Mono.
And now the interesting part!
The launcher implements in C++ miscelaneous functions which are exposed to the mono runtime as internal methods of my game engine classes. That is why my game engine assembly is nothing without the launcher which implements a huge part of the engine in C++.
The question: How am I supposed to debug my C# assembly? And what is more important, how am I supposed to debug a Game which I am going to write in C# ???
As you understand I cannot debug the assembly using MonoDevelop Debugger because it won't receive internal C++ implementations of some of its methods.
What I need is to run the Launcher. The launcher then will launch C# assembly using embedded mono runtime. And then I need something to connect to the launched assembly to allow its debugging.
Or any other way. Thank you!
I recommend using the Mono Soft Debugger. It's been included in the Mono runtime since Mono 2.6, and is more reliable than the old hard debugger, and also much more portable.
The Mono soft debugger can be started by passing options using the --debugger-agent commandline argument to the Mono runtime. This can be done from an embedding host by constructing a fake set of commandline arguments and passing it to mono_jit_parse_options. For example, the Moonlight browser plugin uses the debugger agent values from MOON_SOFT_DEBUG environment variable if it is set.
Typically debugger options are something like
--debugger-agent="transport=dt_socket,address=$ADDRESS:$PORT"
which will cause the app to try to connect to debugger listening on the given address, and pause until it establishes a connection. Note that the connection is established over TCP/IP, which means remote debugging is very easy to set up, and even on the local machine you would use localhost. Additional options are documented on Mono's man page.
The other piece you need is the debugger GUI/controller, to listen for the connection from your app, and handle stepping/visualizing, etc. I would suggest using MonoDevelop. There's a library for the debugger wire protocol called Mono.Debugger.Soft.dll, but it's fairly low-level, and although Mono Tools for Visual Studio supports connecting to the soft debugger, it's not yet extensible in a way that would allow debugging Mono embedding hosts.
Using MonoDevelop to accept debugger connections from embedding hosts currently requires creating an addin, but this is fairly straightforward. Take a look at the Moonlight debugger addin for an example. For simple use cases I would suggest that you don't define a whole new project type but just create a debug handler that handles existing DotNetExecutionCommand projects, so you can run->run with...->your custom debugger.
The monodevelop-list mailing list is a good resource if you have more questions.
Make use of network debugging.
You could use the Soft Debugger to debug the Mono parts, and then use remote debugging for the C++ parts.
Related
I am developing a DLL for a game. And sometimes I encounter errors, but to find these errors, I have to spend a lot of time searching in my code. The DLL is launched through an injector program that implements the DLL into the game process. What is the most convenient way to debug a DLL in my case?
You're on the right path by following the steps in this document.
What you need is to launch the game from the debugger, by setting it as the command line as shown in the document. Note that this won't work for all games since games typically have some kind of anti-debugger protection.
After launching the game and attaching the debugger, start your injector separately to inject your DLL into the game. Your injector should not use manual mapping or other techniques that hide or strip information from your DLL, I recommend using the good old LoadLibrary method.
For convenience, use Debug multiple processes to start the injector with the game and not have to run it manually.
If the steps described above didn't work due to the game protection, the last option is to use Cheat Engine to debug in assembly.
I'm trying to rewrite IL code dynamically at runtime. While this is quite well documented for .NET framework applications by using the Profiling API I can't find anything similar for UWP applications.
Because I have a suite of automated function tests, I need to setup the profiling environment and start a sample app programmatically.
Attempt 1
This question explains how to enable a debugger (as far as I understand a profiler is essentially a debugger) and programmatically start a UWP app.
So from my bootstrapper I call IPackageDebugSettings::EnableDebugging followed by IApplicationActivationManager::ActivateApplication.
Anyway I can't figure out how to implement the debugger. The debugger (which is an executable) is called with the following arguments:
-p 3836 -tid 6180
Both numbers change on every run. While p seems to be the process id of the debugged process, I have no idea what tid could be or how I have to use the arguments to control the debugged app (register for module load events, trigger rejits etc.).
Attempt 2
I found this issue on the Core CLR repo which is about enabling the Profiling API for Core CLR apps. The issue contains a link to a sample profiler repo.
So profiling for Core CLR apps seems to basically work the same way as it does in .NET framework apps (with some restrictions). From my bootstrapper I tried to set the appropriate environment variables (i.e. CORECLR_ENABLE_PROFILING, CORECLR_PROFILER and CORECLR_PROFILER_PATH) followed by IApplicationActivationManager::ActivateApplication.
However the profiler doesn't attach.
I'm quite sure that in general it is possible to profile UWP applications because JetBrains' dotTrace can do it.
Any ideas?
What is this Common Language Runtime that I've been hearing about?
I've recently started a project to create my own, small, personal windows application. I've used DirectX for drawing in the window and such before, for games and whatnot, however this time, I wanted to make it a more standard style application, with menus, and selectable text, and right clicking.
I've searched, but I found no information on how to actually write code for such things, I've only found things telling me to use the drag-and-drop form interface, for windows.
Anyways, I've found that using the forms, actually lets me see the code behind it, too, so I guess I could learn that way....
...but its forcing me to compile using CLR. Why? What is CLR? Can I not create this style of windows application without it?
-Stefan
CLR (Common Language Runtime) is a Virtual Machine. Whenever you compile your .Net programs they are converted into an intermediate language whereas a regular compiler would compile to native code of the target platform. Now whenever there is a CLR implementation available for an OS your program will run on that OS. This is how your .Net programs are portable! Read more here http://en.wikipedia.org/wiki/Write_once,_run_anywhere
The CLR is the runtime for the .Net framework.
You can only run .Net code on the CLR.
Since WinForms is a .Net library, you can only use WinForms in .Net.
I have a custom CLI debugger for which I'm interested in a GUI. The debugger exposes an API with simple functions such as GetMemory(), SetMemory(), GetRegister(), Run(), Stop(), Address2Line() etc. through a TCP socket using a very simple protocol.
I'm looking for the easiest, fastest way of connecting it to a GUI. It seems there are many very good graphical debuggers, so after some research I think these are my best options:
Write a GDB translator - that will act as a gdbserver on one hand, translating all requests for the debugger, and also translate all events from the debugger to gdb compatible events. Then I can use any of the many gdb front-ends.
Write a Visual Studio Debug Engine
Write a plug-in for Eclipse (or some other open IDE)
Write a fresh GUI myself
So which will take the least effort / time ? Is there another way? Is there maybe a graphical debugger where I can easily define custom functions for debugging?
I would write an adapter so you can interact with something standard like GDB or Eclipse. Writing custom GUI code would be a waste of effort
After Google the issue i found that it was reported already but nothing useful yet from MS. I wonder if any one found a work around it?
Another option is to use windbg. You'll have to do a lot of commands by hand, but it's the best debugger out there. It handles mixed mode without any major issues. It has a bit of a learning curve, but it's very versatile.
Visual Studio's debugger is really not reliable when debugging mixed mode applications. Taken from my answer here #5965771:
If you're trying to debug a piece of native code try to use a native project as the debugger start-up application. Under the project settings, "Debugging" tab set the "Debugger Type" to "Mixed", for us this helped sometimes (the native project can be a DLL for example, simply set your main Exe as debugging target in the project settings);
OR, as already mentioned in another answer: Use WinDbg! With it you can debug both managed/unmanaged mixed code applications much more reliably.
use a different debugger, or don't use the debugger at all, just trace to a file or insert breakpoints in the code with inline assembly language.