[Mono-osx] macpack and args[]

Ian Stoba ian@babcockbrown.com
Fri, 8 Apr 2005 12:57:22 -0700

This sounds very similar to the situation for java applications=20
packaged as .app bundles.

Static command line arguments can be passed through the plist, as=20
documented here:


I suspect this would work the same for mono applications.

I have seen several workarounds for this, where people have created=20
everything from double clickable shell scripts (.command files) all the=20
way through application wrappers for NSTask objects that do nothing=20
more than invoke the target app with a specific set of parameters.

While I don't have specific documentation for it, I get the strong=20
suspicion that the UI guidelines for OS X apps do not allow for the=20
user to specify command line arguments when launching an application=20

On Apr 8, 2005, at 12:41 PM, jeff_grimshaw@comcast.net wrote:

> It looks to me like the native executable created by macpack does not=20
> pass command line arguments.  The executable that mcs creates is fine. =

>  That is, execute
>> mono ~/MyProgram/myprogram.exe FirstArgument
> and args[0] will be "FirstArgument".  But if you instead execute
>> ~/MyProgram/MyProgam.app/Contents/MacOS/myprogram FirstArgument
> then args.Length is 0 (zero).  I suppose this makes sense if the=20
> native OSX executable is a wrapper that loads the mono app.  The=20
> wrapper just isn't passing the args (yet).
> Has anyone else seen this behavior?
> --Jeff
> _______________________________________________
> Mono-osx mailing list
> Mono-osx@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx

This email message may contain information that is confidential and =
proprietary to Babcock & Brown or a third party. If you are not the =
intended recipient, please contact the sender and destroy the original =
and any copies of the original message. Babcock & Brown takes measures =
to protect the content of its communications. However, Babcock & Brown =
cannot guarantee that email messages will not be intercepted by third =
parties or that email messages will be free of errors or viruses.=20

If you do not wish to receive any further e-mail from Babcock & Brown, =
please send an email to opt-out@babcockbrown.com.