<a href="http://VS.NET">VS.NET</a> does allow for you (each developer as it goes in the .user file) to specify a library path for a project, what probably means something like 6. So we end up using a mix of setiing a per project library path (somewhat like 6) and keeping tier0/1 in a common libraries folder (part of 4).<br>
<br>In pratice I&#39;ve noted that even <a href="http://VS.NET/CSC">VS.NET/CSC</a> get confused about such references vs visibility issues and I need to add some more references from the lower tiers,meaning duplicated libs in each subproject folder.<br>
<br>See that the project files (really msbuild files) do have more flexibility than what the IDE provides and sometimes I do hand-tune them to make things easier, while still being compatible with the IDE assumptions.<br>
<br>Fun<br><br><div class="gmail_quote">On Wed, May 20, 2009 at 12:23 PM, Grzegorz Sobanski <span dir="ltr">&lt;<a href="mailto:silk@boktor.net">silk@boktor.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* Jonathan Pryor &lt;<a href="mailto:jonpryor@vt.edu">jonpryor@vt.edu</a>&gt; [2009-05-20 15:59]:<br>
[cut everything about extra copies and referencing]<br>
<div class="im">&gt;       gmcs -t:library -lib:b/bin/Debug,a/bin/Debug c/c.cs -r:b.dll -r:a.dll<br>
<br>
</div>Yeap, all the above is true. And is the same for both VS and Mono.<br>
<br>
But I think, that paszczi in his original mail missed the real problem:<br>
<div class="im"><br>
&gt; Now, if you don&#39;t want to specify the entire assembly dependency chain<br>
&gt; (e.g. you only want to specify b.dll or X.dll, not both a.dll+b.dll or<br>
&gt; X.dll+Y.dll), then you *must* have a copy/symlink:<br>
<br>
</div>The &quot;must&quot; is (un)fortunately not true for VS.<br>
<div class="im"><br>
&gt;       cp a/bin/Debug/a.dll b/bin/Debug<br>
&gt;       gmcs -t:library c/c.cs -r:b/bin/Debug/b.dll<br>
<br>
</div>It is only true if c.cs (c.dll) uses types from a.dll.<br>
<br>
Ex: if a.dll contains class LibA {...}<br>
And b.dll contains<br>
class LibB {<br>
  public string Met1 () { return &quot;hey!&quot;; }<br>
  public LibA Met2 () { return new LibA (); }<br>
}<br>
<br>
I can sucessfully compile c.dll in VS if it only calls Met1, without<br>
referencing a.dll, and without having any copies of a.dll laying around.<br>
(after compiling b.dll I have deleted all a.dll files)<br>
And I can even execute c.dll without having a.dll (as dependecies<br>
are resolved at call time not at startup time. It is the same in Mono<br>
I believe).<br>
<br>
Unfortunately to compile c.dll in gmcs I need a a.dll even if c.dll<br>
does not use any type from a.dll.<br>
<br>
(If b.dll is referencing a.dll but does not have anything from a.dll<br>
in it&#39;s public contract, then c.dll will compile fine in gmcs)<br>
<br>
<br>
Now, some real-life example.<br>
We are building modular software and using a bunch of libraries, for<br>
example: Castle.MicroKernel, Castle.ActiveRecord, etc. (let&#39;s call them<br>
tier 1)<br>
They reference some more libaries. Iesi.Collections, NHibernate (tier 0)<br>
<br>
We build modules (tier 2): ModuleA, ModuleB referencing and using a lot<br>
of tier 1 libraries (Castle.* mainly).<br>
<br>
And those modules are used by some applications (tier 3). Now even if<br>
application is not using any types from Tier1 they are still needed<br>
at compile time (in mono, not in VS). What&#39;s more, even dlls from Tier0<br>
are needed.<br>
<br>
There are different solutions we could use:<br>
1) gmcs could compile like VS, not knowing the types from Tier0/1 -<br>
   ideal<br>
2) reference all dll&#39;s from Tier0/1 in application - bad<br>
3) copy (symlink) all dll&#39;s from Tier0/1 to directory of every Module* (Tier2)<br>
   - that&#39;s what we&#39;ve been using until now. But it started to be<br>
     a real maintenance problem.<br>
4) put all dll&#39;s from all Tiers to one directory - we want to avoid that<br>
5) use MONO_PATH= during compilation to show directories where Tier0/1<br>
   dll&#39;s can be found - we are using it now (I know it is &#39;not<br>
   recommended&#39; :P)<br>
6) use -lib instead of MONO_PATH - but that would still mean adding to<br>
   every project from Tier3 every directory from Tier0/1.<br>
<br>
To sum up - problem is when I&#39;m using b.dll which has something<br>
from a.dll in it&#39;s public API, but I&#39;m not consuming it. I would<br>
like to skip a reference to a.dll in c.dll then.<br>
<br>
(We can ensure in some other way that all needed dll&#39;s from tier0/1<br>
will be available at runtime).<br>
<br>
Uff, a long mail ;P<br>
greets<br>
<br>
silk<br>
<div><div></div><div class="h5">_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Rafael &quot;Monoman&quot; Teixeira<br>---------------------------------------<br>&quot;To be creative means to be in love with life. You can be creative only if you love life enough that you want to enhance its beauty, you want to bring a little more music to it, a little more poetry to it, a little more dance to it.&quot; <br>
Osho <br>