[Mono-osx] Monobjc thread, please comment with your experiences with Monobjc
ajbrehm at gmail.com
Thu Dec 11 10:09:54 EST 2008
I am somewhat familiar with Objective-C and Cocoa and have written a few
small applications for Mac OS. The only major problems I have with
Objective-C is lack of portability and apparently there is no regular
expression class (and no regex functions for unicode strings either).
I use VMware and Vista 64. Otherwise the process is like yours. I described
the general idea for Cocoa# here:
Now I am trying to figure out how to adapt it for Monobjc.
I am thinking the following:
1. Reference Monoobjc DLLs and the Monoobjc nant DLL.
2. Build in Visual Studio. This will copy the DLLs into bin\Release.
3. Copy to Mac OS, create a directory something.lproj for NIB files.
4. Should I create an Xcode project to keep track of files? Would that help
with the *.lproj folder?
5. Modify the appl.build file from the SimpleCocoaApp sample. Change all
relevant paths to point to bin\Release.
6. Build using nant. (Can this be added to Xcode as a build step?)
7. Find Application.app bundle in bin/Release folder.
8. Add Winforms version of application to Application.app/Contents/Windows.
9. Arrange for a shortcut to the binary in /Contents/Windows on the Windows
desktop after installation on Windows. Application.app should be installed
by copying the bundle (folder) into /Applications on Mac OS and "C:\Program
Files" on Windows.
> I agree Monobjc is very useful. I prefer Monobjc over Cocoa#, which I
> very lacking in support. For me I use Parallels to run Visual Studio and
> reference the Monobjc DLLs so that I can use intellisense. Compile there
> work out compile errors. Then in leopard compile again to actually run
> The power of intellisense far outweighs the inconvenience of a second
> My advice, which is what we are doing, is to create a business logic layer
> that is C#. Then on Windows create a native WinForms app and then on Mac
> use Interface Builder to create a native look. You will have to write
> most of the UI code. In theory the majority of logic should be in the
> business shared layer anyway.
> When working on Mac forget what you know about Windows. Do not try and
> mimic the c:\program files or other windows concepts. Embrace the native
> infrastructures of each. Trying to be generic or impose one paradigm on
> other will in the end make your app feel like a hack to end users.
> Best of luck.
> On Thu, Dec 11, 2008 at 7:07 AM, Andrew Brehm <ajbrehm at gmail.com> wrote:
>> I successfully tries out Monobjc yesterday evening.
>> First of all, a big THANKS to the team who wrote it. It's fantastic! I
>> look into it a lot more.
>> For the moment I managed to get it to use a NIB file (can it use XIB
>> and display a window and menu. My only problem really was the build
>> I was confused when my program couldn't find the NIB file. Turns out
>> expects to be packaged up into a bundle.
>> My problems in detail:
>> 1. The build process using nant was a bit confusing, at least for me.
>> Particularly as nant couldn't find gmcs and I had to set a path to
>> manually. G-d knows how nant picked up a path to an old version of Mono
>> (1.2.6) I didn't have installed any more and why the path wasn't updated
>> when I installed Mono 2.0.
>> 2. It took me a while to figure out what to do with the Monobjc nant DLL.
>> know include it in the Visual Studio project and configure the appl.build
>> file to use bin/Release as the tools as well as lib directory.
>> 3. Not a problem, but totally worth mentioning: In Visual Studio
>> intelligence works very well for Cocoa framework classes!
>> 4. I am trying to figure out if it is possible to create a single code
>> that uses either Winforms or Monobjc depending on compiler switches or,
>> ideally, a single binary that uses Winforms or Monobjc depending on where
>> is run. For the second case, the bundle thing might be a problem. I wish
>> Windows would support bundles.* So far my test program is a C# command
>> utility (officially).
>> 5. Monobjc is not known enough. It should be part of the Mono
>> Please, Novell, talk to the Monobjc team! Everything outside the Mono
>> distribution seems very exotic. But Monobjc absolutely deserves to be
>> seriously as a porting tool. Forget REALbasic, Mono and Monobjc is the
>> to go!
>> *I figure it would be a good idea to install Mono programs on Windows in
>> "c:\program files" as bundles and create a shortcut to the
>> "Application.app\Contents\Windows\Application.exe" binary. That way the
>> bundle could be copied between Mac OS and Windows. In the root of
>> "Application.app\" a small Windows program or batch file could create a
>> shortcut on the desktop when started.
>> Any thoughts, experiences?
>> View this message in context:
>> Sent from the Mono - OSX mailing list archive at Nabble.com.
>> Mono-osx mailing list
>> Mono-osx at lists.ximian.com
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
View this message in context: http://www.nabble.com/Monobjc-thread%2C-please-comment-with-your-experiences-with-Monobjc-tp20954195p20957218.html
Sent from the Mono - OSX mailing list archive at Nabble.com.
More information about the Mono-osx