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

[Jonathan Pryor]

I have no way to test this, but (IIRC), .NET will only use the
privatePath attribute to search in *sub*directories, not absolute
directories.

So you can't have an app installed in C:\myapp and add C:\mylib to the
privatePath.

Again, IIRC.

 - Jon

On Mon, 2003-10-27 at 13:18, Matthew Mastracci wrote:
> 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
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list