[Mono-devel-list] Guidelines: Application Deployment; Feedback requested.

[Ben Maurer]

Hey,

On Sun, 2005-06-26 at 15:30 -0400, Miguel de Icaza wrote:
> Your C# should reference its data files using the following code
> snippet:
> 
>     string base_directory = System.AppDomain.CurrentDomain.BaseDirectory;
> 
> Then you can do things like:
> 
>    string splash_file = base_directory + Path.PathSeparator + "splash.jpg";

Maybe it would make sense to encourge people to do something that would
work for .dlls as well as .exes. typeof (blah).Assembly.Location could
be used.

Of course, embedding resources is probably the most idiot-proof way to
store data.

> The script in PREFIX/bin typically contains the following two lines:
> 
>   #!/bin/sh
>   exec /usr/bin/mono PREFIX/lib/APPLICATION/app.exe

How about putting "$@" after to pass arguments? We could also give it in
the form so that it can be created by configure:

exec @MONO@ @prefix@/lib/MYAPPLICATIONNAME/app.exe "$@"


> This is where the PREFIX/lib/APPLICATION directory comes into play.
> This for example would allow developers to deploy applications that
> use for example an under-development binding for OpenGL or the iPod
> for example without forcing the developers of the bindings to
> stabilize their API and maintain multiple versions of the library to
> allow old applications to run.

There's got to be a link to msdn about choosing to use the GAC.

Of course, one other advantage of non-gac'd installs is that they are
more relocatable. In fact, you could do xcopy deploy that way. It really
only makes sense to use the GAC if what you are deploying is a shared
library, right?

Some other things that might be worth talking about:

      * Storing application settings (how to use S.Environment to get a
        location for preferences. Having both global and per user prefs)
      * What to do if your application also has a C component?
      * Providing pkg-config files (for libraries)
      * lib/APPLICATION vs lib/mono/APPLICATION (I don't even understand
        this ;-)

-- Ben