[Mono-list] MonoDocumentRootDir for virtual hosts / dll library

[Chris Aitken]

> On Thu, 2005-01-20 at 10:59 +0000, Chris Aitken wrote:
> [...]
> > What purpose does the MonoDocumentRootDir serve?
> > Currently, when I start mod-mono-server, it sets the Root 
> Dir to the 
> > current directory. If I have:
> >    <add key="MonoDocumentRootDir " value="/tmp" /> Then it set the 
> > Root Dir as /tmp.
> > 
> > But what is the difference - why would I be bothered about 
> about where 
> > the root dir is?
> 
> If you run it as a 'daemon', you might want to set the root dir to '/'
> to prevent problems when unmounting devices.

Other than that, is there any other reason?
 
> > AND....How does the mod-mono-server know where my global 
> application 
> > cache is?
> 
> mod-mono-server does not know. The mono runtime does.
> 
> > Under Debian's original setup, when defining a web-app (with 
> > mono-server-admin.conf), one would define a --lib (which for some 
> > reason the example was set for /usr/share/dotnet/lib - an 
> empty directory).
> > 
> > My libraries are in /usr/share/dotnet/mono/gac. Is there 
> any need to 
> > pass this location (I know I can put dlls into the local 
> application cache ).
> 
> The best choice is to add those to the gac. Otherwise, you 
> can use MONO_PATH (see 'man mono').

I get it, so mono actually knows where the assemblies are, and as
mod-mono-server is run by mono, then everything is happy.

Do you have a command that adds dlls to the gac properly. Everytime I have
tried they do not get added in the same way as the others. In Debian,
installed assemblies appear in:

/usr/share/dotnet/mono/gac/ASSEMBLY.NAME/1.0.numbers/ASSEMBLY.NAME.dll
And
/usr/share/dotnet/mono/gac/ASSEMBLY.NAME/2.0.numbers/ASSEMBLY.NAME.dll

With symlinks:

/usr/share/dotnet/mono/1.0/ASSEMBLY.NAME.dll
/usr/share/dotnet/mono/2.0/ASSEMBLY.NAME.dll

Do I need to create the symlinks by hand? Whenever I install assemblies into
the gac:

gacutil -I ASSEMBLY.NAME.dll -package ASSEMBLY.NAME

The files do not end up in the same place/structure as the others!

Any clues?

Cheers

Chris


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.