On Wed, 2009-05-20 at 13:18 +0200, paszczi wrote: > I recently found very annoying thing about mono compiler. Let's say > that we have the following file structure > > lib/X/X.dll > lib/Y/Y.dll > > Where X.dll depends on Y.dll > Now I try to compile project Z which references X.dll and Y.dll. ... > VS compiler somehow manages to resolve those dependencies ...
VS solves this by doing *lots* of copying -- if X.dll depends on Y.dll, then there will be *two* copies if Y.dll: lib/X/X.dll lib/X/Y.dll lib/Y/Y.dll thus allowing things to Just Work. (And if the assemblies are large, it'll eat fair bit of disk space with all the copies running around.) > Currently I'm using a rather nasty workaround: in lib/X/X.dll i put a > symlink to Y.dll but again this creates a lot of mess. This isn't much different than VS's "copy all dependencies" approach, other than saving disk space and being generally saner. What sort of mess does this actually create? > Is there anyway this behavior can be bypassed (via some env > variable)?. Also, you can provide paths to -r:, so this works: gmcs -t:library c/c.cs -r:b/bin/Debug/b.dll -r:a/bin/Debug/a.dll where c.dll depends on b.dll which depends on a.dll, without having extra copies around. Or use -lib: gmcs -t:library -lib:b/bin/Debug,a/bin/Debug c/c.cs -r:b.dll -r:a.dll Now, if you don't want to specify the entire assembly dependency chain (e.g. you only want to specify b.dll or X.dll, not both a.dll+b.dll or X.dll+Y.dll), then you *must* have a copy/symlink: cp a/bin/Debug/a.dll b/bin/Debug gmcs -t:library c/c.cs -r:b/bin/Debug/b.dll - Jon _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list