Mono Adds Mac OS X Package

Good news for those of you who've went through the pain of trying to get Mono installed on Mac OS X: the team has quietly added a Mac OS X package. If you previously installed to /usr/local, however, be aware that the packaged version installs to /opt/local and adjust any paths accordingly. The Beta-1 Windows installer has also been fixed; download it here.

Comments

Usability?

[polyp2000]

Is Mono actually in a state where it can be deployed?

Re:Usability?

[bay43270]

It's in it's first beta. 1.0 is due at the end of June. Here's the story. And the roadmap

Re:DeDRMS

[byolinux]

Miguel has tried it albeit on GNU/Linux.

Is .Net on OS X a Good Thing?

[mr_tap]

I am sure that others have expressed this view before, but is this necessarily going to be A Good Thing? Isn't this going to lead to developers less likely to have special OS X ports that take advantage of specific OS X features?

Don't mean to be a whiner of course :)

Re:Is .Net on OS X a Good Thing?

[bay43270]

I am sure that others have expressed this view before, but is this necessarily going to be A Good Thing? Isn't this going to lead to developers less likely to have special OS X ports that take advantage of specific OS X features?

I think this is a great thing for OSX. OSX support will lead to full featured mono cocoa bindings. This will allow mono and .net developers to port the core logic of thier applications to the mac and still take advantage of OSX facilities for the UI and IO.

Sure, there will always be the lazy programmers who just use mono's winforms implementation to move a windows app to the mac (like all those ugly X11 apps being moved to the mac today). In .net, those winforms implementations can be treated as a stop-gap until a new UI can be written for the app in cocoa#.

I think mono is going to draw out a lot of windows programmers who always wanted to write for the mac or linux, but never wanted to learn the languages (Objective-C or C). Now they can keep working in C#, VB, or whatever. They just pickup a new API (cocoa# or gtk#) and start coding 'native' mac or linux apps.

Re:Is .Net on OS X a Good Thing?

[JimRay]

I've wondered this myself, especially given the "embrace and extend" mentality of Microsoft's past, but ultimatley I'm convinced that Mono on OS X is a good thing for the same reason Perl or Apache on OS X is a good thing. Like it or not, .Net seems not to suck. Like it or not, there seems to be a burgeoning open source community embracing .Net.

For instance, I'm an Actionscript developer. A project I've taken great interest in is ASDocGen, which aims to bring JavaDoc-like functionality to Actionscript. This project is written in C# with the express purpose of being multi-platform via Mono.

In the end, it makes OS X a richer platform to develop on. Rather than be limited to a few tools to do my job as a web developer, I have a vast array of options, from open source web servers to GUI text editors to Photoshop -- I can even open Word docs that clients send me without a problem. Having another tool in my aresenal only makes me a better developer.

Apple has a very strong, committed developer base. They will continue to push great products for OS X. The ability to run some .Net apps will only make OS X better.

Re:Explanation of /opt/local and /usr/local

[frankie]

/usr/local is a commonly used place in many unixish OSes, but Apple likes to think different. This means that whenever you install a Mac upgrade (or even certain updates) there is a possibility that any non-Apple additions to /usr (also /dev, /bin, /var, /etc) will be overwritten by Apple.

Therefore, the safe-but-annoying choice is to put your 3rd party stuff somewhere else. For example, Fink defaults to the (previously nonexistent) /sw directory. Likewise, /opt does not exist in OSX (unless you install this Mono package)

Re:Aha!

[Alrescha]

"Godamnit, I'd just started to get over those fink morons and their /sw tree, now we gotta put up with an /opt."

Where do you think it should go?

It is a long-standing philisophy in some software development circles that you never install your software into system directories (/bin, /usr). If you're adding something yourself it goes into /usr/local. /opt was used for other software providers stuff.

I think /opt and /sw are much better than installing into system-provided directories (which is an insane practice).

A.

Re:Explanation of /opt/local and /usr/local

[sleepypants]

Back in my slackware linux days, I always treated /opt as the location to install whole application trees, kind of like the "Program Files" directory in Windows. So if I download Mozilla, which untars into a "Mozilla-1.6" directory or something, I put it into /opt.

Of course, if I was using slackware's 'official' package of Mozilla, it would probably put all the binaries in /usr/bin, all the libraries in /usr/lib and so on. But for downloading and trying out nightly builds or betas, I would always use /opt.

/usr/local mirrors the structure of /usr (i.e. has bin,lib,share,src,etc.) so it was the place to install software that followed that structure.

Finally. . .iFolder

[Aiua]

I am excited about this quiet release. First, it opens up the possibility of compiling Novell's OSS iFolder on Mac OS X. Second, 60% of the computers in my company run Mac OS X, allowing for greater compatability between the remaining 40%. Third (and relating to the first), there was a recent evaluation of deploying iFolder company-wide, and the missing Mac OS X support was a critical issue. Now, the chances of the deployment happening have increased with the relase of Mono for Mac OS X. This should be great news for Apple fans.

Re:developer

[OmniVector]

yes. and you could develop on your mac for some time now by installing mono via darwinports or fink.

seems superfluous...

[javax]

superb. Mono is available via DarwinPorts for a rather long time already.
Why should we need this so urgently? There is no package for Debian or FreeBSD either... no one with a brain would think about making packages for those!

mod_mono compile fix

[chasingporsches]

for any of you that have tried to compile mod_mono 0.9 with the apple GCC and apache 1.3 stock installs, you may notice that it fails on "sudo make install" because it compiles it to a dylib instead of a so. here's a workaround: cd mod_mono-0.9/src; apxs -c -o libmod_mono.so -DAPACHE13 -I../include/ -I/usr/include/httpd/ mod_mono.c; apxs -i -a -n mono libmod_mono.so

Re:Aha!

[Smurf]

If you can't build a package that understands its own paths, and is re-locatable to any location, then its -not- finished, and you shouldn't release it.

I agree that all packages should be re-locatable. Unfortunately there are lots of *excellent* Unix/Linux and (gasp) Windows applications that are path dependent. I agree that they should be fixed when porting them to OS X, but meanwhile I prefer to have them even if they are "the result of laziness".

OSX is a Unix for Users. Use it that way!

Yes, but please don't break Unix in the process. Linking /proc to ~/proc is a terrible idea. MacOS X is finally a good multiuser system. Finally, all the members of a family or a workgroup can have their files in their own accounts without creating chaos and endangering the system. That's the goal of the users home directories.

By linking proc to ~/proc, you will limit the use of Mono (or whatever is installed in /proc) to one user (unless you duplicate it in every user account). Programs that should be available to all users should NOT be installed in a particular user's directory. That's a terrible practice. If you are so convinced in thinking different(ly), link it to /Users/Share/proc, but then again you have an absolute path.

Whose "utter"?