35

I need a conditional compilation switch that knows if I am compiling for the mono or MS .NET runtime. How can I do this?

Will Dean
  • 39,055
  • 11
  • 90
  • 118
Frep D-Oronge
  • 2,618
  • 3
  • 27
  • 27

2 Answers2

60

The Mono compiler defines __MonoCS__

BUT, BUT, BUT, the whole point of Mono is that you can take an assembly that you built with VS and run it on Mono, or vice versa.

It seems to me that if you need to have Mono vs MS.NET differences, then you need to be making those decisions at run-time.

The standard way to detect Mono at Runtime is:

bool runningOnMono = Type.GetType ("Mono.Runtime") != null;
Will Dean
  • 39,055
  • 11
  • 90
  • 118
  • 7
    Understand the point but Mono has a lot of catching up to do in places, and there is no point penalising the MS build... Good tip though thanks – Frep D-Oronge Dec 02 '08 at 11:18
  • 2
    One use case is having GTK# GUI on Mono, and Windows.Forms GUI on .Net. – Ivan Vučica Mar 01 '11 at 20:26
  • Will - the problem I was having was with the behaviour of WinForms BindingSources bound to objects implementing INotifyPropertyChanged. Obviously that was a while ago and it maybe OK now. – Frep D-Oronge Feb 10 '12 at 10:45
  • If you're using one click deployment and you have a global error handler that grabs one-click information from `System.Deployment` you'll have to conditionally compile otherwise. – Chris Pfohl Sep 28 '12 at 16:31
  • Sometimes it is necessary to use macro as Mono will fail to compile what compiles just fine on Windows. For example: `AppDomain.CurrentDomain.FirstChanceException` is just not defined on Mono. – Sergiy Belozorov Mar 24 '14 at 19:30
  • 4
    @Will Dean You occasionally need to use conditionally compilations. E.g. Mono doesn't support the attribute; ViewStateModeById which triggers a runtime failure if you've tagged a class with it. So what you're saying is not completely accurate... – Thomas Hansen Nov 30 '08 at 17:15
  • I'm not familiar with that attribute, but that still seems to me that the future presence or absence of the ViewStateModeById attribute is not something which *directly* correlates with the compiler which was used to compile your assemblies. But there's always __MonoCS__ if it does... – Will Dean Nov 30 '08 at 18:07
  • @Will It will trigger a runtime failure when trying to load the assembly... :( But in general terms I agree with you, though it's not always possible... – Thomas Hansen Nov 30 '08 at 18:46
  • 1
    BUT BUT BUT it isn't the whole point of Mono that you can take an assembly that you built with VS and run it on Mono, or vice versa. It depends on the platform.... what about Xamarins products for mac and mobile??? they invented mono and they don't do this. So you are clearly wrong. While it does work sometimes it doesn't with others. – AnthonyLambert Jan 26 '15 at 10:50
  • @AnthonyLambert - Look at the date of my reply - it was written before Xamarin even existed. – Will Dean Jan 26 '15 at 13:13
  • Wow you're right..... doesn't time fly.... anyway things change and if left that way it is misleading and wrong for today's audience. – AnthonyLambert Jan 26 '15 at 15:45
  • I want to compile code in Mono that uses an assembly that isn't on Mono `using System.Deployment.Application;` - this can't possibly work at runtime because the using statement doesn't compile on Mono. With a compile switch I can do it. – PandaWood Aug 06 '18 at 13:01
1

It is clear that there are times when code on one platform will differ to code on another and you may wish to do this at run-time or maybe compile time. Some times it can't be done at run-time.

For example:

Mono is used as the basis of Xamarin's Ios, Android, and Mac tool kits. While these have a lot of common code they also have classes which only appear on a single platform. When developing with these tool kits you develop native packages which are not exchangeable between platforms.

A simple case is file names and paths. These differ on each platform. I just might to have a little condition to load the strings differently on each platform. Some platforms have case specific file names some don't.

It would be nice if there was a little bit of code which returned the current platform - be it UNIX, iOS, Mac, X86, X64, XBox etc....

AnthonyLambert
  • 8,768
  • 4
  • 37
  • 72
  • 1
    .NET already has abstractions for handling paths portably. `System.IO.Path.DirectorySeparatorChar`, for example. So, no need to build your own logic to handle the different OS possibilities for that case. – Nate C-K Jan 23 '15 at 16:54