[Mono-dev] Resolving dependencies while compiling

[Grzegorz Sobanski]

* Jonathan Pryor <jonpryor at vt.edu> [2009-05-20 21:23]:
> gmcs is currently being modified to use Mono.Cecil instead of
> System.Reflection.Emit, which should make gmcs act more like .NET here.

That's what I had understood from some bug reports, good :)
 
> > There are different solutions we could use:
> > 1) gmcs could compile like VS, not knowing the types from Tier0/1 -
> >    ideal
> 
> This should eventually work with either Mono 2.6 or 2.8, due to the gmcs
> Cecil migration.

That would be really nice.

> > 2) reference all dll's from Tier0/1 in application - bad
> Not sure why this is bad.  Annoying, certainly, but bad?

Yes, 'bad' is maybe a too strong word.
>From a technical point of view, everything is ok. But in practice, in
non-trivial appliaction it is very, very annoying.
First, you get all namespaces from all libraries available in code
completion. Types/namespaces that shouldn't really be used at that 
tier are avaialbe to programmer, etc.
If any lib changes it's dependent libraries it's hell.
You must add references to all projects if lib adds new dependency.
If some lib drops dependency, you don't event know you can drop it from
you libs, etc.
Really annoying ;)

> > 3) copy (symlink) all dll's from Tier0/1 to directory of every Module* (Tier2)
> >    - that's what we've been using until now. But it started to be 
> >      a real maintenance problem.
> 
> Someone off-list mentioned that svn + symlinks == pain, so I can see how
> this would be problematic.

True, first it sometimes just breaks. Second, creating them is annoying ;)

> > 4) put all dll's from all Tiers to one directory - we want to avoid that
> Not sure why you want to avoid this, considering that to _run_ your app
> (for testing, etc.) you'll need all of these assemblies in the same

True.
Problem is we have one application, that's dynamically loading modules
at runtime. So, we don't need all aseemblies in output directory of
every module. The server has references to all (or most of) libraries
from Tier0/1, so they are in output directory of the application
when it is run (that answers the question about how we ensure having 
the libs at runtime).

Comming back to the question.
At the moment we are using about 10-12 outside libraries at tier 1. 
And 4 libraries developed in-house. Many of those libraries comes
with more then 1 dll (NHibernate and Castle with many more).

So, putting them all in one directory, and adding references to them
means .dll hell, and problems when libs are updaed to new version etc.

...
Oh, wait, I think I understand now.
You mean - only coping those dll's to on dir at build time (or repo
update time), and only use this directory during build, not to add
references.
That's some idea :) But I think it is very similar to setting MONO_PATH?



All our problems are really coming from few requirements:
- we are lazy ;)
- we don't want maintance problems when upgrading libraries,
  quessing where dll's comes from (so we keep per-library dir)
- we want to develop the same project in both windows nad linux,
- we want to use .csproj for both IDEs - VS and MD (it is working
  great, btw),
- we want the work for developers as smooth as possible
- we would want to avoid having to track few build files and keep them
  in sync
- everything just works ;)

Ok, I know, daydreaming ;-)

Have a nice weekend.
silk