+Q: What is a 100% .NET application?
+
+A: A `100% .NET application' is one that only uses the APIs defined
+ under the System namespace and does not use P/Invoke. These
+ applications would in theory run unmodified on Windows, Linux,
+ HP-UX, Solaris, MacOS X and others.
+
+ Note that this requirement also holds for all assemblies used by the
+ application. If one of them is Windows-specific, then the entire program
+ is not a 100% .NET application.
+
+ Furthermore, a 100% .NET application must not contain non-standard data
+ streams in the assembly. For example, Visual Studio .NET will insert a
+ <tt>#-</tt> stream into assemblies built under the "Debug" target.
+ This stream contains debugging information for use by Visual Studio .NET;
+ however, this stream can not be interpreted by Mono (unless you're willing
+ to donate support).
+
+ Thus, it is recommended that all Visual Studio .NET-compiled code be
+ compiled under the Release target before it is executed under Mono.
+
+Q: Can I execute my Visual Studio .NET program (Visual Basic .NET, Visual C#,
+ Managed Extensions for C++, etc.) under Mono?
+
+A: Yes, with some reservations.
+
+ The .NET program must either be a 100% .NET application, or (somehow) have
+ all dependent assemblies available on all desired platforms. (How to do so
+ is outside the bounds of this FAQ.)
+
+ Mono must also have an implementation for the .NET assemblies used. For
+ example the System.EnterpriseServices namespace is part of .NET, but it
+ has not been implemented in Mono. Thus, any applications using this
+ namespace will not run under Mono.
+
+ With regards to languages, C# applications tend to be most portable.
+
+ Visual Basic .NET applications are portable, but Mono's
+ Microsoft.VisualBasic.dll implementation is incomplete. It is recommended
+ to either avoid using this assembly in your own code, only use the
+ portions that Mono has implemented, or to help implement the missing
+ features. Additionally, you can set 'Option Strict On', which
+ eliminates the implicit calls to the unimplemented
+ Microsoft.VisualBasic.CompilerServices.ObjectType class.
+ (Thanks to Jörg Rosenkranz.)
+
+ Managed Extensions for C++ is least likely to operate under Mono. Mono
+ does not support mixed mode assemblies (that is, assemblies containing both
+ managed and unmanaged code, which Managed C++ can produce). You need a
+ fully-managed assembly to run under Mono, and getting the Visual C++ .NET
+ compiler to generate such an executable can be difficult. You need to use
+ only the .NET-framework assemblies, not the C libraries (you can't use
+ <b>printf</b>(3) for example.), and you need to use
+ the linker options <tt>/nodefaultlib /entry:main mscoree.lib</tt> in
+ addition to the <tt>/clr</tt> compiler flag. You can still use certain
+ compiler intrinsic functions (such as <b>memcpy</b>(3)) and the STL.
+ You should also see <a
+ href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vcgrfconvertingmanagedextensionsforcprojectsfrommixed-modetopureil.asp"
+ >Converting Managed Extensions for C++ Projects from Mixed Mode to Pure
+ Intermediate Language</a> at MSDN.
+ Finally, you can use PEVERIFY.EXE from the .NET SDK to determine if the
+ assembly is fully managed.
+
+ Thanks to Serge Chaban for the linker flags to use.
+