[Mono-osx] macpack and args[]

[Ian Stoba]

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:

http://developer.apple.com/technotes/tn/tn2031.html

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
bundle.


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.