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

Ian MacLean 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 
forward.

Ian








More information about the Mono-devel-list mailing list