You did not provide any relevant information on the project, so I cannot give you a recipe to overcome the problems, but there are things you need to understand correctly.
First of all, this is
not cross-compilation. This is the compilation using different compilers
for the same platform. .NET CLR and Mono are different implementations of the same platform. The fact that the assembly runs in the same way
without recompilation is just one of the aspects of this fact.
At the same time, there is a number of incompatibilities between those implementations I've personally detected for different versions. I haven't use Mono for a while and cannot tell you any detail on the latest versions. However, all incompatibilities I saw are related to the implementation of some FCL types, and some, but very few of them were related to BCL. For example, I saw considerable incompatibilities in
Form
rendering.
(Please see:
https://en.wikipedia.org/wiki/Standard_Libraries_(CLI)#Base_Class_Library[
^],
https://en.wikipedia.org/wiki/Framework_Class_Library[
^].)
By the way, the violations of the standard was on both sides, on Mono and on Microsoft's. When Microsoft's implementation was buggy (I faced at least one such case) and the bug was fixed in Mono, it created the incompatibility.
I did not find the incompatibilities between Mono implementations for different OS (I used Windows, Linux and Mac OS X), but some differences between runtime behaviors on different OS are unavoidable. In particular, the part of system architecture related to the "console" are very different in Linux and Windows. Command line interface is very fundamental for Linux (and any kind of *NIX), but not for Windows.
Also, the notion of "console application" in .NET is expressed in a very confusing way, especially in Visual Studio. I don't remember how it looks for MonoDevelop, but its design is very similar to VS. The confusion leads to thinking that the applications are classified into "Window applications" and "console application". This is not so. In reality, the switch simply says that the console should be shown or not. If the application is "console", the console is always shown, but the application can be a Windows application at the same time, or console only, or anything. If the application type is not "console" (and not the library), the console is just not shown, but it may show a window, or nothing. Note that in all these cases you can use
System.Console.Write
, only the result of such output is not visible without console.
I've developed and tested a number of, say,
System.Windows.Forms
applications which worked on Windows .NET, Linux via Mono and Windows via Mono in nearly the same way. They did not show any console on any of the three platforms; and the same story was with Mac OS X. You should just do right thing: locate appropriate "application type" switch and use it the way you want.
I hope my notes can help you to sort out the problem with redundant/annoying console. You did not provide any relevant information which could help me to advise on other problems you faced. Perhaps you should utilize early prototyping and testing before developing bigger applications.
—SA