Bruno Haible wrote:
>>> - Target "install" should install foobar.dll into $(libdir), using
>>> $(INSTALL_DATA).
>>
>>May any post-install action be necessary for the library (on some hosts)?
>
> None that I'm aware of.
Well on windows hosts (and possibly hosts with sscli), there is the
possible (but not required) step of running ngen to generate native
images (for faster execution). This sounds like a step that libtool
may want to provide support for.
>>How does the installed program find its libraries?
>>How the uninstalled?
>
> In both cases: through the -L option passed to csharpexec.sh. Inside
> csharpexec.sh, for some C# engines, the -L option translates into options;
> for others, it translates into the setting of an environment variable.
Well, the .NET system is based around assemblies (a program or library +
associated files). In most cases this is a single DLL or EXE, with the
exception of localization, in which case there will be associated
"satellite assemblies" for each of the supported locales (DLLs that
contain only resources, no code). All these files are treated as a
single entity by the runtime. So if an application references
a "Foo.Bar" assembly, the runtime may end up loading both
/lib/Foo.Bar.dll and /lib/de/Foo.Bar.resources.dll.
As for where it finds assemblies, it looks in the directory where the
main program is located(*), then in the Global Assembly Cache (GAC).
>From what I understand, /lib (or $prefix/lib) acts as the GAC for mono
(and possibly the other implementations). Assemblies need to be
"strong named" (i.e. cryptographically signed) to be allowed in the GAC;
typically only shared libraries will be put in the GAC, and private
assemblies go with the executable (which is a poor match to the Unixy
tradition of putting executables in a single location).
(*) Technically, it's a bit more complicated than this - there's a
class called AppDomain in the runtime that is related to all this;
assemblies are located based on the current AppDomain, and
applications are free to create as many AppDomains as they wish
(e.g. they can create a "Plugins" AppDomain that causes assemblies
to be looked for in, say, /prefix/share/myapp/plugins). But the
default AppDomain is set to load references from the .exe's
directory.
