Journal for 2011

MonoMac video from NDC 2011

The videos from NDC 2011 are now online, including my talk Developing .NET Applications for the Mac App Store (direct link). You can also download a printable version of my presentation. Hopefully there will be an official torrent of the videos soon, because there were plenty of other sessions that are worth seeing. Thanks to everyone who helped make it such a great conference!

Correction: In the presentation I said that native objects don't retain references to managed objects, which is incorrect. The problem I intended to refer to is a common coding error where views are retained but their controllers are not, e.g. mainView.AddSubview(new ChildController().View).

Speaking at DevTeach

This week I'm going to be presenting two sessions at DevTeach 11 in Montreal.

My first topic will be Native .NET Apps for the Mac with MonoMac. I'll be taking about MonoMac and the native Mac APIs that it exposes to .NET developers, and how to build native apps that can be deployed to the Mac App store. My second topic will be Using Mono for Native Apps on Mac, Android, iPhone and more. I'll be giving an overview of Mono's most exciting platform integration technologies: Mono for Android, MonoTouch (iPhone), and MonoMac. I'll also explore strategies to share and re-use code between these and other .NET platforms such as Windows, Silverlight and Windows Phone 7.

I'll also be on the DotNetRocks panel to discuss mobile platforms, and outside my talks I'll be happy to discuss any Mono-related topic, especially the technologies I've worked on — MonoDevelop, MonoTouch, Mono for Android, ASP.NET MVC, and the use of Mono in games.

Preview of Xcode 4 Support for MonoTouch

In their recent update of the iOS and Mac developer tools, Apple removed the standalone Interface Builder application and integrated the GUI designer functionality directly into Xcode 4. This was a very significant change and removed several features that were necessary for MonoTouch and MonoMac to integrate with the designer. As soon as Xcode 4 went final, we started working on MonoDevelop support for integrating MonoTouch with Xcode 4's GUI designer, but it's a complex project and will take some time to complete.

For now we recommend using Xcode 3's Interface Builder, which can easily be done even while having Xcode 4 installed. However, I understand that many people are concerned how Xcode 4 will be better supported going forward for MonoTouch and MonoMac, so I've made a screencast to introduce MonoDevelop's upcoming Xcode 4 integration and demonstrate how it works.

MonoTouch integration with Xcode 4

Although XIB files can be opened standalone in Xcode 4, this isn't very useful, as it's no longer possible to define custom types, outlets and actions within the interface designer. Instead the designer is aware of the Objective-C types defined in the Xcode project that contains the XIB file. This means that we have to generate an Xcode project file and synchronize it with the MonoDevelop project. Since Apple doesn't support writing third-party Xcode plugins, we can't make the Xcode designer directly aware of types defined in C# source, so the generated Xcode project also has to contain Objective-C stubs for all the types defined in C#. The Xcode designer now modifies the Objective-C source files when adding outlets or actions, so those changes need to be synchronized back the the MonoDevelop project.

The new model of Xcode integration resolves several outstanding issues in the previous Interface Builder integration. Because the generated project contains all bundle resources (Content and Page files) from the project, they will now be accessible directly from the GUI designer. In addition, all user-defined types are accessible from the designer, not just those defined for the current xib file.

Obviously, synchronizing files and types between two projects in separate applications is complex, and if anything goes wrong it's possible to lose data, so we want to make sure it's as reliable as possible before we release it. We hope to be able to offer a beta of this functionality within the next few weeks.

Speaking on MonoMac at NDC 2011

I'm going to be at NDC 2011 in Oslo, and I'll be speaking about Developing .NET Applications for the Mac App Store. The talk will provide an introduction to MonoMac and the native Mac APIs that it exposes to .NET developers, explain the structure of MonoMac apps and how they can be deployed to the Mac App store, and discuss strategies for code reuse across the platforms supported by Mono and .NET.

If you catch me outside my talk, I'll also be more than happy to discuss other Mono technologies that I've worked on such as MonoDevelop, MonoTouch, Mono for Android, ASP.NET MVC, and the use of Mono in games.

MonoDevelop Tips will Resume in May

In early February I started writing a series of MonoDevelop Tips, and after a solid run of a couple of months, I found it difficult to keep up with the challenging Mon-Tues-Weds-Thu-Fri schedule I originally set for myself, and had to take a break to catch up with all the other things I need to do. I'm building up a buffer of new posts, and I'll resume posting tips in May, on a Mon-Weds-Fri schedule. Now that MonoDevelop 2.6 beta 2 is out, I'll also start covering some of the new features in 2.6.

Please go back and read the past tips in case you missed any, and rate your favourites — comments and ratings encourage me to keep doing this.

MonoDevelop Tips: Navigate to Line in File

In an earlier post, I introduced the Navigate To dialog, which allows quickly navigating to any file or type in the solution. It has a couple more useful capabilities which are not immediately obvious.

Firstly, it's possible to go directly to a specific line in the selected file by typing a colon followed by the line number. As soon as the colon is typed, the list will narrow down to only contain files, not types or members. When you hit Enter to navigate to the file, you will be taken directly to the specified line, if it's valid.

Navigating to a specific line

This also works in the more specialized Go to File dialog.

Another hidden feature is that it's possible to access several options by clicking on the search icon in the search box.

The Navigate To options

The options that constrain the list's contents are fairly obvious. Disabling "complex matching" makes the searching faster but makes the fuzzy/acronym matching poorer.

MonoDevelop Tips: Document Outline Pad

One of my favourite pads in MonoDevelop is the document outline pad, which provides an overview of the current document and a way to jump quickly to any part of it. I like to keep it autohidden on the left side of the MonoDevelop window, so that I can quickly bring it up. You can show it using the View->Pads->Document Outline menu item, and change its position and docking to fit your workspace layout.

The document outline paf

Clicking on an item in the Document Outline pad will select or focus that item in the document. Outlines are shown for C# source, the GTK# GUI designer, XML, HTML, T4, ASP.NET, and more.

MonoDevelop Tips: Navigation History

MonoDevelop keeps track of your navigation history, like a web browser. If you jump to another file or another position inside the same file, you can easily navigate back. This is particularly useful combined with MonoDevelop's other code navigation features that make it easy to jump around your code, such as the "Go to definition" command and the Navigate To dialog. The Navigation History can get you back to wherever you were before.

To navigate back, use Ctrl-Alt-Left on Window or Linux, or Cmd-Opt-Left on a Mac. To navigate forward, use Ctrl-Alt-Right on Window or Linux, or Cmd-Opt-Right on a Mac.

These commands are also found in the Search menu, along with the Navigation History list, which shows a list of the last fifteen locations, and allows you to jump directly to any of them. Internally it keeps more history than this, but menu space is limited.

The Navigation History menu

The commands are also found in the Navigation toolbar.

The Navigation History toolbar

Navigation points are created whenever you use a command that navigates directly to something, such as opening a file, going to a definition, and so on. If you manually move the caret around a file and stay in one area for more than about 10 seconds, it may also log a navigation point there.

MonoDevelop Tips: Code Focus

Code focus is a useful feature that helps to show the structure of your code. It's activated by hovering over one of the fold markers in the text editor margin for a few seconds. The activated fold region and its parent regions are highlighted using graduated colour differences on the text editor background.

Code focus highlighting regions in the text editor

Code focus can also be toggled on and off from the keyboard using the Control-Shift-K shortcut on Windows and Linux, or Cmd-Shift-K on Mac. When activated in this way it's persistent until toggled off, and it follows the caret, highlighting whichever region it's in.

MonoDevelop Tips: Preferences, Policies and Project Options

There are several different kinds of settings in MonoDevelop — Preferences, Policies and Project Options — and the distinction between them is not immediately clear. This post aims to provide an explanation of them and what they're used for.


Preferences control MonoDevelop's behaviour and appearance, but do not directly affect projects' code or output. This means that they are user-specific, and are stored in the user profile. Examples of preferences are the text editor's colour scheme, whether the text editor shows line numbers, the font used for output pads, whether MonoDevelop jumps to errors after a build, and so on.

The Preferences dialog can be accessed from the MonoDevelop->Preferences menu item on Mac, the Tools->Options menu item on Windows, and the Edit->Preferences menu item on Linux. This is consistent with other applications on these platforms.

Project and Solution Options

Project Options are specific to projects, and affect how they're built and run. This includes things like compiler options, the name of the output file, the arguments used when running the project, and so on. These options are stored in the project file, so other users will be able to build and run the project correctly. Where possible, they are mapped to the options used by Visual Studio and the MSBuild/xbuild command-line build tools.

The Project Options dialog can be accessed from the Project->{Project Name} Options menu item, or from the Options context menu item on the project in the solution pad, or by double-clicking on the project in the solution pad.

Some options are part of a project configuration. Projects can have multiple configurations, so by switching between them you can build different outputs. Configurations will be covered in a future post.

Solution Options are similar to Project Options, but for solutions. The Solution Options dialog can be accessed from the Project-> Solution Options menu item, or from the Options context menu item on the solution in the solution pad, or by double-clicking on the solution in the solution pad.


Policies are settings that affect how projects and code are formatted and organized, such as code formatting settings, naming conventions, and so on. In many other IDEs these settings are user-specific preferences, which means that different users working on the same project do things inconsistently, or have to change their preferences depending on which project they're working. Policies ensure that these settings are consistent for different users working on a project, and make it easy to manage sets of policies across projects.

Because most policies are invariant across all projects within a solution, projects can be set to inherit the policy of their their parent solution or solution folder, and this is the default setting. This means that in most cases, policies only need to be edited on the solution, and these changes will be picked up by the projects. Policies settings panels are shown in the Project Options and Solution Options dialogs. They can be recognized by the "Policy" combo box at the top of the panel, which allows you to pick a policy to use, or set the item to inherit the policy from its parent. Alternatively, you can customize the settings, and the combo will show "Custom".

When a solution is first created, or a solution without policies is saved, it will take its initial policies from the user's default policies. From that point on, they are only stored in the solution and are not affected by changes in the user's default policies, else solutions could not be shared between users and maintain consistent policies.

While Preferences and Project Options are familiar to users of many other IDEs, policies are something unique to MonoDevelop, and hence they sometimes cause confusion. Another post will explore the policies system in more detail.