[Mono-devel-list] Cross Platform .NET Architecture
jonpryor at vt.edu
Tue Mar 15 07:05:32 EST 2005
On Mon, 2005-03-14 at 11:16 -0800, JD Conley wrote:
> Is there any documentation on how Mono sets up its class library
> projects for cross platform .NET development?
Rafael answered this fairly well: stick with portable solutions when
possible, use #ifdefs when they're not, and use design patterns for
runtime selection of appropriate classes (when possible).
> It seems like there would
> be some interesting ways you could do this with attributes rather than
> having IF DEF's everywhere.
In some circumstances, maybe, but in general no. The reason is
interdependencies. Consider the System.dll and System.Xml.dll circular
dependency: System.dll needs to be built twice, once without referencing
System.Xml.dll, and a second time against System.Xml.dll (because
System.Xml.dll depends on System.dll). This must be done with #ifdefs
because we don't want the compiler to see the System.Xml code the first
time it's compiled.
A similar circumstance also applies for the various profiles (NET_1_0,
NET_2_0, etc.) -- you can't let the compiler see code that doesn't
belong to the profile you're compiling, because if it did the compiler
would reference code it shouldn't be (such as referencing Generics when
compiling for .NET 1.1).
Attributes can't help with this scenario, since you're trying to bypass
> Is there a particular subsystem I could
> look at for a good example of how to do this in my own projects? In an
> ideal world we wouldn't have to write any platform specific code, but
> this probably isn't going to happen in my project any time soon.
The more general idea is to use a Factory Pattern: define a base
class/interface, sub-class it for each platform/technology you need, and
define a factory method to choose which class to instantiate.
System.IO.FileSystemWatcher is a perfect example of this, where three
different backends are available (polling, Win32, libfam), and the
appropriate backend is selected at runtime. Attributes could be used in
a more elaborate version of this.
More information about the Mono-devel-list