Install locations on unix was : [Mono-devel-list] Re: Potential GAC implementation ideas.

[Jonathan Pryor]

The obvious solution is to do both! :-)

Which is sort of the only sane approach, as well.

For .NET compatibility, the app and its private assemblies must be in
the same directory (assuming that you don't create your own AppDomain,
change it's setup, etc.), or in a /bin sub-directory.

So, by default, you'd have a directory with:

	myapp.exe
	mylib1.dll
	mylib2.dll
	...

So, what's the sanest way to place this on Linux, while maintaining .NET
compatibility for assembly loading?  Place the app in
/usr/share/apps/<appname/>:

	/usr/share/apps/myapp/myapp.exe
	/usr/share/apps/myapp/mylib1.dll
	/usr/share/apps/myapp/mylib2.dll
	/usr/share/apps/myapp/...

Of course, you want an easy way to start your program, so create a file,
/usr/bin/myapp, with contents similar to:

	#!/bin/sh
	mono /usr/share/apps/myapp/myapp.exe

Or, use a symlink (assuming that binfmt_misc is installed).

You're done.  Most of this can be accomplished with a ZIP file, which
just contains myapp.exe & its libraries.  Installation consists of
unzipping the ZIP into the appropriate directory (wherever you want),
and creating the script.

Creating an RPM that does that should be fairly trivial.

 - Jon

	


On Sun, 2003-10-26 at 22:53, Ian MacLean wrote:
> >
> >
> >Assume I'm application developer. I have an assembly that is quite private
> >for me, i.e. I see no particular reason anybody else would use it. So I
> >place it in /usr/share/apps/foobar/mydll.dll, or something like this. How
> >do I tell where this DLL resides to the runtime? My app wouldn't reside
> >in /usr/share/apps/foobar/foobar.exe, since in UNIX world it should
> >go to /usr/bin/foobar.exe. 
> >
> 
> Does this hold for .net apps ? Should they really install to 
> /usr/bin/foobar.exe ? If you deploy a java app as a runnable jar its not 
> usually added to /usr/bin so why should a .net exe assembly be any 
> different ? A .net exe assembly has more in common with a runnable jar 
> than a traditional binary - the fact that it comes packaged in a windows 
> PE file is purely a convenience for running on a windows platform.
> I think the java approach is a good model here. Multi platform java apps 
> usually have the same directory structure across platforms ( the root 
> will be different obviously ) and then they provide some sort of native 
> stub for launching on each platform - a shell script for *nix and a 
> small compiled exe launcher for windows. Given that the bulk of ms .net 
> apps will be designed with the assumption that library assemblies ( dlls 
> ) will reside in the same directory or a subdirectory ( or gac ) does it 
> make sense to make this the reccomended install policy for mono apps as 
> well rather than forcing a /usr/bin install ?
> The ms.net assembly probing mechanism also relys on this same directory 
> assumption looking first in the GAC, then the containing dir of the 
> calling exe then subdirs and so forth. I'm not sure if this is going to 
> be emulated on mono or not. However having different assembly resolution 
> algotithms across platforms could lead to some interesting bugs going 
> forward.
> 
> Ian
> 
> 
> 
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list