As some of you may have noticed, Monobjc is under heavy development to support the newly released version of Mac OS X 10.7, also known as Lion. Thanks to the architecture redesign performed under the version 3.0 (the native runtime), the transition is smooth and easy. A preview release of Monobjc for Lion should be out by the end of the month.
Thursday, March 3 2011
Image that your .NET application uses an assembly. When compiled, the application references the exact version of that assembly. If a new minor of this assembly is installed, your application will not use it unless a policy told her so. This is fine in most cases, as it avoids the DLL hell issue.
But, the problem with assembly policy is that the oldVersion attribute cannot be a wildcard. You have to specify the exact old version of assembly to redirect to the new one. This can be a problem when you have several versions of the assembly and want to redirect them to the latest version.
There are two solutions for that: - Define as much redirect as there is old versions of the assembly. This is the explicit way. - Although oldVersion attribute cannot be a wildcard, it can be a range. All you have to do is to define the lower and upper bound of the version. This is the implicit way.
Here is an example of range use:
<configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Monobjc" publicKeyToken="d5a8d181860c16be" /> <bindingRedirect oldVersion="10.5.0.0-10.5.65535.65535" newVersion="10.5.1492.0"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration>
This policy will redirect any assembly whose version begins with "10.5" to the newVersion.
Thursday, November 11 2010
It is been a while since I blogged about Monobjc. Some people may have thought that the project was in sleep (or worst dead), but it is not.
I work on Monobjc on my spare time, which means that the project does not go as fast as I would. And as the last six months have been quite harsh for me on the business side, I spent very few hours on the Monobjc project. But, now that the situation is back to normal, I can dedicate more resources to the project.
In this post, I will try to summarize the current state and the future of the project.
I am working on the next iteration of the Monobjc project now for eight months. It can be considered a very long time, but the current design has proven to reach its limits when I was working on two new main features: categories and 64 bits support.
As for now, the Monobjc project is lacking on the following points:
- The support for PowerPC architectures is broken since Mono 2.6. I spent a lot of time to figure why Monobjc crashes on Mono 2.6 when it was working perfectly on Mono 2.4. Note that this issue is bound to PowerPC only.
- The support for 64 bits systems. Now that experimental build of Mono can be built, it would be great to have access to the power of 64 bits architecture in Monobjc applications.
- The support for categories is missing. Even so it does not seem important, I think it is a really handy feature to add to subclassing and composition. It works the same way as extension methods in .NET.
- The support for blocks. This addition from Mac OS X 10.6 is used extensivly in the new APIs.
- A proper set of tools, including a decent MonoDevelop plugin set.
A New Design
The PowerPC issue and the 64bits support are part of the same approach. The current design, mostly managed code, is too hard to debug or to alter in order to support a new architecture properly. So I sat down and though about the most efficient architecture that would allow a transparent support of 32/64 bits architectures and maybe solve the PowerPC support issue. I came to the conclusion that the managed side of the bridge was too clumsy.
The design I came to will be based on a custom Mono runtime, containing the Monobjc extensions (messaging, bridging, class registration, etc). It is close to what you can find in others Cocoa/XXX bridges like RubyCocoa or PyObjc. With that design, the managed code of the bridge is greatly reduces as well as the manipulation of the native structures. The diagram below summarized the idea:
What does it means for every developpers ? Well, almost nothing. The tooling part of Monobjc will take care of the custom runtime and the changes are minor. This leads to a painless migration when transitionning to the new design.
More Unit Tests
While working on the categories, I realized that the Monobjc project was not tooled enough for regression and unit testing. The current state of the unit tests is pretty awful, so the next iteration of the project will focused on a better support for unit and regression testings.
Flexible Wrapper Generation
For almost three years, I used several tools to generate the Cocoa wrappers, which involves scapping sources, fixing it by hand to have a decent result. But when dealing with new classes, it is not sustainable anymore. That why I decide to rethink entirely the wrapper generation. This is an ongoing work, but the result can be seen by cloning and building the monobjc-generator project on GitHub.
The current state of MonoDevelop integration is pretty light. The plugin set was created by Eric Butler but its maintenance requires a lot of work, and the project is now considered D.O.A. Speaking of proper tools, the MonoDevelop plugin set will be of course part of it.
What about MonoMac ?
As stated in this post, the choices will favor developers. The Monobjc project remains dedicated into providing the best .NET/Objective-C bridge, along with a proper tooling. What is important to me is to provide a complete toolchain that enable developers to focus on their application instead of the development process.
That is all for now. I hope that my fellow readers will find this information useful. I am eager to get some feedback on that and on the Monobjc project in general.
Friday, December 18 2009
Wednesday, April 29 2009
Monobjc 2.0.342.0 was released on April 2009, the 15th. One major addition in Monobjc is the support of SM2DGraphView graphing framework. It is the first round to include a graphing framework, and I hope to enhance the support in the next releases.
Sunday, December 21 2008
Monobjc 2.0.313.0 was released on December 2008, the 17th. One major addition in Monobjc is the support of Sparkle update engine. Sparkle is one of the most used framework in the Cocoa world, as it makes updating an application a breeze. The main problem with Sparkle in Monobjc was the private framework embedding. With Sparkle, updating a Monobjc application has never been so simple. Check out the tutorial for Monobjc and Sparkle.
Saturday, December 13 2008
Thursday, November 13 2008
Many people want to package their .NET application for Mac OS X. And above all, they want the experience to be painless, which means that they want to ship an application that runs, whether Mono is installed or not.
The process of packaging a .NET application for Mac OS X basically follows 4 steps:
- Getting .NET dependencies of the .NET executable
- Generating a native loader that will embed all the .NET assemblies (.NET executable and .NET dependencies)
- Getting native dependencies of the native executable
- Relocating all the stuff so library loading goes well
The process can be even more complicated if you are using reflection, dynamically discovered library and so on. So let's keep thing simple.
Getting .NET dependencies
This is the easy part. You just have to find recursively all the .NET dependencies of the .NET executable. As every .NET assembly contains its references, it is trivial.
Generating a native loader
The native loader generation is simplified by the fact that Mono allows .NET assemblies to be loaded from embedded binary streams. So for every .NET assembly, we generate a binary array and use the magical functions of Mono. If there are configuration files to embed, the process is the same.
Getting native dependencies
Once the native loader is compiled, the
otool command can give us all the native dependencies. So we gather all the native library needed to run our application. But on Mac OS X, the dynamic loading is based on paths recorded in each native library. This is the point of the next step.
Relocating all the stuff
This is the tougher part of the packaging. Now that you have all the native dependencies, you must be sure that you only have unique dependencies. Why, because we you gather dependencies, you can find either specific version of a library or compatibility version of a library. Failing to make these reference unique can lead to unexpected behavior (mostly cryptic crashes). That where the
otool command is useful as the first line always contains the specific version of a library, even if run against a compatibility version symbolic link. Then the
install_name is used to change absolute path to relative path containing the macro
Packaging made easy
All this steps can be tedious and error prone. That's why, in the Monobjc, the packaging is done by a NAnt task: <mkbundle/> (you can find its options on this page). This task can handle most of the need for .NET application packaging in a truly simple way. And as a bonus, this task is not linked to the Monobjc bridge, so you can use it even if you don't use the Monobjc bridge.
Sunday, September 14 2008
Monobjc is more than one year old, and the time has come to go beyond the Monobjc bridge. In order to develop the .NET programming on Mac OS X, a bridge is not enough. A whole development ecosystem is needed, so any new developer will have all the necessary tools to leverage the power of .NET on Mac OS X. I have identified several tools needed when developing applications:
- IDE: An IDE is great as it speeds up the edition on multiple document and centralized the application development (code writing, compilation and packaging). Unfortunatly, an IDE is a very complex machinery. Identified solutions: fork SharpDevelop or MonoDevelop.
- Reflector: A tool like Red Gate Reflector is useful when dealing with assemblies. The though part is to write the IL reverse-engineering engine. Identified solution: a Reflector clone based on Mono Cecil.
- Obfuscator: When distributing applications, obfuscation is an additional mesaure to protect your investment. Identified solution: an obfuscation tool based on Mono Cecil.
Monday, August 11 2008
A while ago, Luke Hoban implemented a ray-tracing sample application. I have made a Cocoa port of this application by using the Monobjc bridge, and it was over in less than one hour. Here is a screenshot:
You can download the source code as part of Monobjc.
« previous entries - page 1 of 2