F.A.Q

General
Contributions
Licensing
Runtime
Development
Miscanellous

General

What is Monobjc bridge ?

The Monobjc bridge is a collection a .NET libraries that enabled a .NET application to use the Mac OS X native libraries such as Cocoa, WebKit, etc. The native libraries are exposed through a set of class that makes their use very easy, because no native code is involved. The Monobjc bridge goal is to ease the access of the major Mac OS X native libraries.

Why using Monobjc bridge ?

The .NET programming languages (especially C#) are very popular. The .NET runtime provides a lot of built-in functionnalities and a lot of .NET libraries are available to build very quickly an application. So, if you want to leverage the power of .NET and use the Mac OS X specific libraries such as Cocoa, the Monobjc bridge is the appropriate tool.

How Monobjc bridge works ?

The Monobjc bridge provides .NET wrappers for Objective-C types exported by various Mac OS X frameworks. This mechanism allows any .NET applications to access the Mac OS X frameworks as if they were .NET libraries. In addition, .NET class can be exported to the Objective-C runtime to be transparently called within native code. The Monobjc bridge takes care of all the machinery behind.

What kind of API does the Monobjc bridge exposes ?

The Monobjc bridge exposes all the major Mac OS X framework such as Cocoa, WebKit and Quicktime. Any .NET application can access these frameworks as if they were .NET libraries and leverage the power of Mac OS X frameworks in a simple way.

Why does Monobjc bridge come in two versions ?

The Monobjc bridge comes in two versions, because of its support for both Mac OS X 10.4 and 10.5. The assemblies versionned 1.0 only contains wrappers for Mac OS X 10.4 API, and the assemblies versionned 2.0 contains wrappers Mac OX X 10.5 API.
If you want to target both Mac OS X 10.4 and 10.5, you should develop your application with the 1.0 assemblies, and if you want to target Mac OS X 10.5 only, you can develop your application around the 2.0 assemblies.

What is the difference with the Windows.Forms port included in Mono ?

The Windows.Forms port included in Mono is focused on cross-platform ability to run .NET code that relies on the Windows.Forms UI. This port relies on the mapping of the Windows.Forms UI to Mac OS X UI using native API. The Monobjc Bridge takes a different approach: it provides a direct access to the Mac OS X UI API as the RubyCocoa and PyObjc projects do.

What is the difference with the GTK driver included in Mono ?

The GTK driver included in Mono is focused on cross-platform ability to run .NET code that relies on the GTK# UI (based itself on GTK). This port relies on the mapping of the GTK UI to Mac OS X UI using native API. The Monobjc Bridge takes a different approach: it provides a direct access to the Mac OS X UI API as the RubyCocoa and PyObjc projects do.

What is Monobjc NAnt Tasks ?

The Monobjc NAnt tasks are a sub-project of the Monobjc bridge. It contains all the building tools to help the development of .NET/Cocoa applications.

Contributions

How can I help Monobjc ?

The best way to help Monobjc is to use it, so you can spot what is working, what is brobken or what is missing. Your feedback is important to us.

When I donate money, how is it used ?

The donations are used for:

Licensing

Which license does Monobjc bridge uses ?

The Monobjc project is licensed under the GNU Lesser General Public License v3.0 or later.

Why the Monobjc bridge is using the LGPL license ?

The Monobjc bridge is using the LGPL license to ensure a widespread adoption of the technology. The LGPL has all of the restrictions of the GPL except that you may use the code at compile time without the derivative work becoming a GPL work. This allows the use of the code in proprietary works. The LGPL license is completely compatible with the GPL license.

Where can I get more informations about the LGPL license ?

For more information on the LGPL, you can visit the Free Software Foundation's FAQ: http://www.gnu.org/licenses/gpl-faq.html.

Can I use the Monobjc bridge in an other Open Source project or product ?

You can freely modify, extend, and improve the Monobjc project source code in an other Open Source project. The LGPL requires that all changes must be made available if the combined work is distributed. For more information on the LGPL, you can visit the Free Software Foundation's FAQ: http://www.gnu.org/licenses/gpl-faq.html.

Can I use the Monobjc bridge in a commercial product ?

You can freely modify, extend, and improve the Monobjc project source code in a commercial product. The LGPL requires that all changes must be made available if the product is distributed. For more information on the LGPL, you can visit the Free Software Foundation's FAQ: http://www.gnu.org/licenses/gpl-faq.html.

What is the essential difference between the GPL and the LGPL ?

When code licensed under the GPL is combined or linked with any other code, that code must also then be licensed under the GPL. In effect, this license demands that any code combined with GPL'd code falls under the GPL itself.

Code licensed under the LGPL can be dynamically or statically linked to any other code, regardless of its license, as long as users are allowed to run debuggers on the combined program. In effect, this license recognizes kind of a boundary between the LGPL'd code and the code that is linked to it.

If I redistribute my Monobjc based application as a native binary, what are the licenses that apply ?

The Monobjc building tools generate an application bundle that is compliant to both licenses of Mono and Monobjc. The Monobjc project permits binary embedding into the generated binary. As long as you comply with the LGPL license, there is no problem.

Why Monojbc NAnt Tasks is using the GPL license ?

The Monobjc NAnt Tasks are using the GPL license, because it contains code that provide very useful processing. The GPL forbids its inclusion in proprietary tools, so the community keeps a strategic advance with the code.

If Monojbc NAnt Tasks is licensed under GPL license, does it means that things generated with these tasks are also under GPL license ?

No, not at all. Only the source code of the Monobjc NAnt Tasks is licensed under the GPL. All the generated stuff (source code, bundle, NIB) keep its original license, whatever it is.

Runtime

What is the minimum version of Mac OS X to run Monobjc bridge ?

The Monobjc Bridge requires at least Mac OS X 10.4 (a.k.a. Tiger).

Does Monobjc bridge works with Tiger (Mac OS X 10.4) ?

Yes, it works on Mac OS X 10.4. The bridge automatically detects the proper runtime to use.

Does Monobjc bridge works with Leopard (Mac OS X 10.5) ?

Yes, it works on Mac OS X 10.5. The bridge automatically detects the proper runtime to use.

Does Monobjc bridge works with Snow Leopard (Mac OS X 10.6) ?

Yes, it works on Mac OS X 10.6, although it has not been heavily tested. Some people have problems, bu they seem due to issue with the Mono runtime.

What are the requirements for Monobjc ?

The only requirement is to have a Mono runtime installed. If you consider doing some development with Monobjc, you will need the Apple XCode Developer Tool, mainly for the Interface Builder application and the GCC/LLVM compiler.

Does Monobjc needs X11 ?

No, it does not. Monobjc only relies on standard Mac OS X technologies and it does not use X11 at all.

Does Monobjc bridge works on 64 bits hardware ?

Yes, it should work on 64 bits hardware but it has not been tested yet (volunteers or donation needed !!!).

Development

Which frameworks are available through the Monobjc bridge ?

The list of the exported frameworks is available here. More framework will be added in the future.

What the limitations of the Monobjc bridge ?

Yes, the Monobjc bridge has some limitations. the current list.

Can I use the Monobjc bridge in C#/VB.NET/MC++/F#/My Language ?

Yes, you can. As long as the language is supported by the .NET runtime (i.e. can be transformed into IL), there is no limitations other than those of the language.

How do I develop my own application ?

At the moment, there are no integration in XCode. But since Mono 1.2.6, the MonoDevelop IDE is included. Another solution is to develop using an IDE on another platform running in a virtual machine.

How do I package my own application ?

A tutorial is available to show how to do this.

How do you create the user interface ?

Like any other Cocoa application, with the Interface Builder tool. Refer to the Cocoa Application tutorial and the Programming Guide for more informations on how to use the XIB/NIB files generated by this tool.

How can I redistribute my Monobjc based application without requiring Mono installation ?

A tutorial is available to show how to do this.

Is there an Interface Builder integration ?

The Monobjc NAnt Tasks give a basic level of integration, by providing a way to generate source code that contains IBOutlet/IBAction mapping from a XIB or a NIB file. You create your GUI under the Interface Builder tool, and then run the custom task to get a ready to use source code. See for more details.

Is there an XCode integration ?

Not for the moment, but it is planned. A C# plugin is available (Do a Google search for it) but it only provides basic functionality (no code completion).

I found a bug. What should I do ?

You should report it in the tracking system. Please indicate all the informations that can help.

Miscanellous

What is the planned release cycle for Monobjc bridge ?

A new release of Monobjc bridge is planned every month or every two months (6 to 10 releases a year). Each release may contains API enhancements, bug fixing, new features or anything valuable. The Monobjc bridge can be seen as a sort of continuous project (perpetual enhancement), focused on functionalities, ease of development and stability.

Is there any similar products or projects ?

Similar projects exist: Dumbarton, ObjC#, Cocoa-Sharp, NObjective. Both Dumbarton and ObjC# focused on the integration of .NET into the Objective-C runtime (when you have a large Objective-C code base) whereas Cocoa-Sharp, NObjective are focused on the Objective-C integration into the .NET runtime (when you have a large .NET code base).

Why creating Monobjc bridge instead of re-using/re-writing/contributing to XXX ?

At first, it was the way we envision when we started to work on the bridge. After all, some projects were around for many years and seem pretty good. But there were things like the lack of documentation, the existing code, no means to simply debug the bridge, partial APIs, etc., that promotes the fact that eventually a new clean-room bridge implementation was needed. So we started to code from scratch a brand new engine by using the concept of parallel hierarchies between .NET and Objective-C and dynamically generated proxies.

Monobjc is similar to Cocoa-Sharp. Is it a derivative work or a fork ?

Monobjc is NOT a derivative work or a fork of Cocoa-Sharp. Monobjc shares some concepts with Cocoa-Sharp (parallel hierarchy between .NET and Objective-C, dynamically generated proxies, pure .NET solution, use of attributes to expose classes) but it does not use any code from Cocoa-Sharp. You can see clear differences in the way architecture and Objective-C versions are managed, the way messaging is done and a lot of other points.

How are generated the wrappers (methods, documentation, etc) ?

Well, a bit of mistery is always good, isn't it ?