views:

89

answers:

2

Hi! 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!

A: 

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.

supercheetah
A: 

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.

mhutch
mhutch, thank you a lot! During last two days I came to the solution you suggest. Currently I was digging into default MonoDevelop addins sources. Thank you especially for "Moonlight debugger addin" link! And I came to another soultion too. Looks like I can use Managed C++ (C++/CIL) to connect my C++ routines with C# assembly. So I can have two configurations one for debugging purposes and this will be MSVC debugger + Managed C++ Launcher + C# debugee. And the second for platform independ release builds using Mono embedded runtime.
Anton Petrov
Yes, if you design your app so it can run using either Mono or .NET, you can use the awesome .NET mixed-mode debugger on Windows. I would recommend avoiding C++/CLI though, as it's not at all portable. The mixed mode debugger works fine with P/Invokes, and they *can* be portable...
mhutch
I do not want to use P/Invoke in release builds because of performance benefits which Mono internal call give. But P/Invoke with C++/CIL allow me to debug my code with "the awesome .NET mixed-mode debugger on Windows" as you said. I have tried all this out and it works great.
Anton Petrov