[Mono-devel-list] Compiling class libraries using VS.NET

[Richard Thombs]

Thanks Jon and Rafael, that makes sense!

R.

-----Original Message-----
From: Jonathan Pryor [mailto:jonpryor at vt.edu] 
Sent: Friday, October 17, 2003 5:02 AM
To: Richard Thombs
Cc: Mono Development List
Subject: Re: [Mono-devel-list] Compiling class libraries using VS.NET


Why the duplication?  To minimize dependencies.  Cross-Assembly
dependencies.

There are a number of classes that are used used extensively, across all
assemblies.  MonoTODOAttribute is the predominant example.  Now, suppose
that we only had one MonoTODOAttribute, a public one in corlib.dll.

That would require that all other assemblies that use MonoTODOAttribute
(most of them) to have a dependency on Mono's corlib.dll.  Which means
you couldn't use them under .NET (or Rotor, or PNet).  This is
undesirable (it minimizes what testing we can do, who can use the
assemblies, etc.).

Instead, we try to keep inter-Assembly dependencies identical to .NET
(increasing portability).  Any additional classes that are used are
individually copied into each Assembly and marked "internal," so that
other Assemblies won't accidentally depend on the Assembly.

Is this ideal?  Perhaps not.  But it's the (current) best of the
non-ideal choices.  (Other choices include using .netmodules to hold the
shared code, and "linking" the .netmodules into each assembly that needs
them.  The problem with this is it leads to a multi-file Assembly, which
makes deployment more difficult.  Worse, mcs doesn't support .netmodules
yet.  The ideal choice would be a way to integrate .netmodules into a
single-file Assembly, but I don't think that's possible yet.)

 - Jon

On Fri, 2003-10-17 at 00:45, Richard Thombs wrote:
> Hi,
> 
> To make it easier for me to browse and trace through the Mono source, 
> I wrote a tool that creates a VS.NET project from all of the files in 
> mcs/class. While trying to get the resulting project to compile, I 
> noticed that there were a few duplicate class definitions that I 
> couldn't explain. Most of them have to do with a definition existing 
> in corelib as well as in some other location.
> 
> For example: System.IO.MonoIO is declared both in 
> class\System\System.IO\MonoIO.cs and class\corlib\System.IO\MonoIO.cs
> 
> I was wondering what the purpose of this duplication is and if there 
> are any hard and fast rules about which I should include and which I 
> should ignore?
> 
> Thanks,
> 
> Richard.
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com 
> http://lists.ximian.com/mailman/listinfo/mono-devel-list