please use the attribute [MonoTODO]. This attribute can be used
to programatically generate our status web pages:
- [MonoTODO]
+ [MonoTODO("My Function is not available on Mono")]
int MyFunction ()
{
throw new NotImplementedException ();
}
+ Ideally, write a human description of the reason why there is
+ a MonoTODO, this will be useful in the future for our
+ automated tools that can assist in developers porting their code.
+
* Supporting .NET 1.2, .NET 1.1 and .NET 1.0 builds
The defines NET_1_1 and NET_2_0 are used to include
From that point on a list of changes in a file-by-file basis,
describing what changes were done.
+
+ This information must be cut and pasted into your commit
+ message, so the information ends up in two places: in the
+ subversion repository metadata and also on the source code
+ distirbution (which does not have the Subversion metadata).
* Warnings
}
}
}
-
+
+* Conditional compilation
+
+ Ideally we would not need conditional compilation, and the use
+ of #ifdef is strongly discouraged. But due to our support for
+ old C# 1.0 compilers we have to use it in a few places.
+
+ Try to avoid negative tests that have an else clause, for
+ example:
+
+ #if !NET_2_0
+ CODE_FOR_1_0
+ #else
+ CODE_FOR_2_0
+ #endif
+
+ Instead use:
+
+ #if NET_2_0
+ CODE_FOR_2_0
+ #else
+ CODE_FOR_1_0
+ #endif
+
+ When a major feature differs across compilation targets, try
+ to factor out the code into a separate class, a helper class
+ or a separate file, and include that in your profile while
+ surrounding that helper file/class with the ifdefs to reduce
+ the amount of ifdefs in the code.
+
+ For instance, this is used for some parts of Grasshopper where
+ the code is ifdefed out, when large parts of a file would have
+ been ifdefed out, we moved the code into a MyOtherFile.jvm.cs
+
+ For 2.0 classes, this is even simpler as code can be trivially
+ factored out into
+
+ MyHelperClass.cli.cs
+ MyHelperClass.jvm.cs
+
+ By using partial classes.
\ No newline at end of file