


This allows the MonoDevelop IDE to know where in the source code the compiled code maps to.īecause of this, you should make sure that when you distribute your applications, or if you’re doing performance testing, your application should be done via a Release build. A Note About Debug Buildsĭebug builds are much slower and much larger than release builds because every line of code is instrumented to have information that points back to the original source code. When you run a MonoTouch application as a debug build, it tries to establish communication with MonoDevelop, if it finds a listening MonoDevelop, it performs a handshake and then continues on with application. This is interesting to us because you can actually debug MonoTouch code running on the iPhone itself, over a Wi-Fi network! There are a few limitations (of which we’ll take a look at later), but for most application development, you likely won’t run into them.Īdditionally, what’s really cool about the Soft-Debugger, is that they loosely coupled the underlying protocol over which the debugger uses. What this means for you, is that debugging in MonoTouch now acts, essentially, the same way you’ve come to expect debugging for any other.

The Soft-Debugger is actually based on a Java pattern for debugging and is called a “Soft-Debugger” because it’s actually a piece of software that is integrated into the MonoDevelop (or other IDE) and calls an interface which is now included as part of the Mono Runtime. They chose the latter, and in MonoTouch 1.2, they released the Mono “Soft-Debugger”. So the MonoTouch team would have had to either reverse-engineer the protocol, or implement a new methodology altogether. You could still use Apple’s XCode application to debug your application, but it wasn’t very useful because it had no way of mapping the compiled instructions (assembly) back to the original source code (symbols). Because Apple is so secretive, however, they don’t publish the information about the debugging protocol. In order to do this however, the debugger must have intimate knowledge of the underlying runtime of the code (and privileges to change the memory where that code is running), as well as communicate via the proper protocol to access the runtime to do what it needs to do. NET, or other modern platforms), actually inject small bits of code into your code that allow them to do things like pause your application and allow you to step through it. Most sophisticated debuggers (the kind that you’re probably used to if you’re coding in. This means that your application starts up and the debugger reads the information in memory that belongs to the threads that your application is using. Modern debuggers typically work by “attaching” to a running process.

The reason was, Apple is very, very tight-lipped about the details of the iPhone OS innards. Microsoft Azure supports your workload with abundant choices, whether you're working on a Java app, app server, or framework.
