Install locations on unix was : [Mono-devel-list] Re: Potential GAC implementation ideas.
ianm at ActiveState.com
Sun Oct 26 22:53:29 EST 2003
>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
More information about the Mono-devel-list