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

Matthew Mastracci matt at aclaro.com
Mon Oct 27 13:18:11 EST 2003


One additional note - .config files can always be used to redirect the 
private bin path as needed:

<configuration>
     <runtime>
         <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
             <probing privatePath="/usr/lib/myapp/support/"/>
         </assemblyBinding>
     </runtime>
</configuration>

Jonathan Pryor wrote:

> 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





More information about the Mono-devel-list mailing list