Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What, if any, are the Microsoft supported options for running C#/.NET 4.0 code natively on the Mac? Yes, I know about Mono, but among other things, it lags Microsoft. And Silverlight only works in a web browser. A VMWare-type solution won't cut it either.

Is there any semi-authoritative answer to why Microsoft just doesn't support .NET on the Mac itself? It would seem like they could Silverlight and/or buy Mono and quickly be there. No need for native Visual Studio; cross-compiling and remote debugging is fine.

The reason is that where I work there is a growing amount of Uncertainty about the future which is causing a lot more development to be done in C++ instead of C#; brand new projects are chosing to use C++. Nobody wants to tell management 18–24 months from now "sorry" should the Mac (or iPad) become a requirement. C++ is seen as the safer option, even if it (arguably) means a loss in productivity today.

share|improve this question
    
Supported by whom? By Microsoft? No, there ain't. But this isn't a code-level question, so you should ask it on programmers.stackexchange.com. –  Jonathan Grynspan Feb 15 '11 at 19:35
    
Can there be too many SO sites? :-) Is there a simple way to move this question there (now that I've created an account)? –  Dan Feb 15 '11 at 19:43
2  
Supported by whom? –  user1249 Feb 15 '11 at 20:01
2  
Crossposting is not allowed. Generally, flag for mod attention and we can migrate for you. What we want to avoid, however, is the loss of all the effort put forward by the people who answered. I'll migrate and ask the mods at PSE to merge. If anybody here has an account over there they should get the rep. –  Will Feb 15 '11 at 20:06
1  
@Will I merged them. Thanks. –  Anna Lear Feb 15 '11 at 20:14
show 4 more comments

13 Answers

up vote 11 down vote accepted

is there any semi-authoritative answer to why Microsoft just doesn't support .NET on the Mac itself?

The best answer is probably that you don't "just support" .NET on the Mac. You spend hundreds of millions of dollars and several years porting .NET to the Mac.

While some things are fully managed and would not require porting, most things are wrappers around the Win32 API (windows, controls, gdi+, cryptography, active directory, COM, enterprise services, device access, sound, video, codecs, winforms, etc, etc).

Every single one of these would have to be abstracted in the backend and remapped to equivalent native libraries on OSX. Of course, there's not going to be a nice clean mapping, so you also have to write hacks upon hacks to get it functioning exactly the same.

Then there's the issue that these APIs on OSX can be brittle and Apple isn't very good at backwards compatibility, so you get to redo your hacks with every major release (and sometimes minor release and hotfixes), racking up a high maintenance cost.

Basically, it's a tremendous amount of money and work for very little gain on a platform whose owner would be against you doing it anyways. And you don't really want to spend money to help people migrate off of your own platform onto a competitor's.

So you are left with not-perfect cross-platform choices:

  • C++, which will still require porting in the future
  • Silverlight out of the browser, for Microsoft support
  • Mono, which does the work to support a healthy subset of .NET, but isn't Microsoft
share|improve this answer
1  
You spend hundreds of millions of dollars and several years porting .NET to the Mac. Excuse me? That number sounds a little high...I'm pretty sure the Mono-Framework (with support for many more OSs) didn't cost that much. –  Bobby Feb 16 '11 at 11:41
1  
@Bobby: that's what I'm thinking. Mono+Silverlight seems most of the way there. Add to that some P/Invoke and/or C++/CLI for less mainstream stuff (Cryptography, AD, etc.) and I think you'd have a pretty reasonable solution at reasonable cost. My argument is that Microsoft DOES want to spend money helping people get on OSX; if they don't, people will stop using C#/.NET on Windows. –  Dan Feb 16 '11 at 14:36
    
@Dan: Exactly, Microsoft does not want to be compatible with the world, otherwise the world could use something different. ;) –  Bobby Feb 16 '11 at 15:11
6  
The Mono framework is also not a complete, fully tested, documented, supported solution. There is a difference in what's "good enough" for open source and the quality people expect from Microsoft. It would easily cost hundreds of millions of dollars for them to do it to the level users would demand. What they could do to lessen the investment would be to pick out a popular (and portable) subset of the .NET framework and just do it. That's what they chose to do, they call it "Silverlight". –  jpobst Feb 16 '11 at 15:58
add comment

No, Silverlight is the only Microsoft option from .Net on OS X. Mono does not "lag" as much as you think; it supports .Net 4.0 and C# 4, for example. However, the UI toolkits (WinForms and WPF) are not well supported on OS X. Mono doesn't support WPF at all. Neither could Microsoft without rewriting the entire rendering engine. That's probably OK, though. If you want to write a native Mac app, you should be writing a native UI (perhaps using MonoMac).

share|improve this answer
    
Management doesn't seem very inclined to go along with the Mono option. And it certainly didn't support .NET 4.0 on the same day as on Windows (or?). –  Dan Feb 15 '11 at 19:47
    
Isn't Silverlight already most of the way there on the WPF(-like) front? Yes, the XAML would need to be different to get a Mac look-and-feel. –  Dan Feb 15 '11 at 19:52
2  
@Dan: The way Mono moves these days, if you start developing an app for the latest version of .NET when Microsoft releases it, Mono will support that same version by the time that app is ready to ship. –  Anon. Feb 15 '11 at 20:13
    
@Dan SL and WPF under the covers are attempting to merge as much as possible. There are technical differences but the fundamental concepts are cross platform. –  Aaron McIver Feb 15 '11 at 20:21
5  
If your companies management is not willing to use Mono then you will be unable make a desktop application written in traditional C# 4.0 its just that simple. –  Ramhound Feb 15 '11 at 20:29
add comment

No. Mono's your best bet.

Other open source projects like DotGNU may serve you as well. http://www.gnu.org/software/dotgnu/ But none of these is MSFT supported.

share|improve this answer
add comment

Silverlight is not browser only. Since version 3 OOB has existed and would be the route I would take if a Microsoft supported platform is a must-have.

While Mono may lag it is not as removed from the .NET stack as you may think and should not be cast aside as a viable option.

As to why Microsoft does not implement the entire .NET stack; ROI.

share|improve this answer
    
But it seems like they're oh-so-close with Silverlight...why not just finish the job? That would seem so much better for everybody than Mono reverse-engineering the compiler, CLR, etc. –  Dan Feb 15 '11 at 20:25
1  
SL is not the entire .NET stack. The SL runtime versus the entire .NET stack are completely different animals. –  Aaron McIver Feb 15 '11 at 20:27
    
Yes, but since you can already do things like OOB as you suggest with SL, why not port the rest (1/3? 40%?) of the .NET stack? Or is SL really nothing more than an attempt to kill Flash? –  Dan Feb 15 '11 at 20:30
    
@Dan When companies are pushing things to the cloud...the last thing that you want to do is port a stack over that can't run in the cloud. SL can run across browsers. You can argue with the likes of Google and others the push for working within a browser is real. Why at this moment would you then opt to port an entire stack to an OS with < 10% market share along with virtualization so prevalent in this day and age? –  Aaron McIver Feb 15 '11 at 20:44
    
Microsoft (arguably) has the best development environment available today with C# and .NET. But companies like mine will increasingly shy away from it because of the Uncertainty surrounding the Mac/iPad/cloud/etc. C++ seems much safer. –  Dan Feb 15 '11 at 20:50
show 1 more comment

Most of Microsoft’s profit comes from two products - Windows and Office. Cross platform compatibility would hurt Windows.

If you really want the same code running cross platform, write a web app. It doesn't sound like you do though. “Just in case” isn’t a good reason, it’s scope creep.

Even if you do decide to target Mac OS X or iOS in 16 months from now, do you really think you could take your existing C++ code and turn it into a good (or even functional) native app? Unless you're working on a full-screen game, the answer’s no.

Save time with C# now, and if you decide to move onto the Mac, rewrite it the Mac way with Objective-C and Cocoa - your users will thank you.

share|improve this answer
1  
"Just in case" is the reality; no one wants to tell management "oops" when there is a safer option in C++. –  Dan Feb 15 '11 at 20:36
1  
Assuming the interface code is properly separated, it will be easier to move C++ code onto the Mac. Rewrite the interface in Objective-C using Cocoa, link to the rest, and you've got a whole lot of the job done. –  David Thornley Feb 15 '11 at 20:43
    
@David: and hence the problem behind this question: more C++, (much) less C#. I (really) like C#! –  Dan Feb 15 '11 at 20:51
    
These cross-platform concerns right here is why a lot of us are still using Java and not moving to C#. –  Brian Knoblauch Feb 15 '11 at 20:54
add comment

is there any semi-authoritative answer to why Microsoft just doesn't support .NET on the Mac itself?

Where's the market that would justify MS spending the treasure coding it? In order to do this, they'd have to drop serious cash--millions of dollars in salary. An ongoing process, as fixes and updates come along.

And for what? Bragging rights? All they get out of it is the ability for people to ditch Windows for Apple and be able to still run their apps.

If anyone would profit from doing this, it would be Apple. Make it easier for people to transition to their platform and for developers (DEVELOPERS DEVELOPERS) to code on it. But do you think SJ gives a crap? They'd rather invent new stuff to stick an i infront of. Besides, most of the framework is OS and the CLR specs are free for anybody to implement. You can't stick a filthy NDA on any of it.

share|improve this answer
    
Part of "what's in in for Microsoft" is to keep people using their top-notch tools on Windows. The way things are going around here, C#/.NET will be relegated to in-house apps. Developers who have been using C# for years are writing C++ again. As for the cost; it would seem like they're about 2/3 there already with Silverlight and/or Mono. –  Dan Feb 15 '11 at 20:14
    
Mono is an open source platform, and while the source for .NET has been released, the .NET Framework is NOT open source. Microsoft will be unable to purchase Mono, for many reasons, the major one is that they do not have a single 100% open source application. Do you know know that Silverlight is only a single language within the .NET and the reason it is multi-platform because Microsoft would like it to be a replacement for Flash. I should also add that Apple has made hand movements towards not even allowing something this on their operating system. –  Ramhound Feb 15 '11 at 20:26
    
@Ramhound "Open Source" as in you can view it without breaking any kind of license, not as in some neckbeard in Shamokin Dam can fork it, prepend "Awesome" to every class name, and release it as "Awesome.NET". –  Will Feb 15 '11 at 20:44
1  
@Dan sounds like the solution to your woes isn't "one language to rule them all" but "How do we deploy in a platform-agnostic manner." Most people are accomplishing this by breaking the UI from the logic, embedding one on a per-platform basis and the other as a service on the innertubes. –  Will Feb 15 '11 at 20:47
1  
@Dan I have a solution for that... Don't code for the Mac. I have a personal Non Develop-for-Apple Agreement I wrote and signed myself. I would utterly hate not being able to code C#, and so avoid doing so. But sometimes you gotta do what you gotta do, and if wishes were fishes we'd have to think up some other alliteration to describe the many things we want but cannot have. –  Will Feb 15 '11 at 21:00
show 1 more comment

Let me answer this directly: no, there is not officially Microsoft supported way to do this.

share|improve this answer
    
Part of what's behind this is "why not?" (intelligent speculation). We're a major commerical software vendor...if we're going away from C# it could end up being used only for in-house apps. –  Dan Feb 15 '11 at 19:42
    
@Dan It is not supported because Microsoft does not wish to extend the functionality of .NET to other platform themselfs. You might want to look into the "hourglass of Apple" and see they are moving away from anything that isn't natively written fro OS X itself. Just 6 months ago they would reject an iOS application written in .NET and then ported for the platform ( there are commercial applications that support this ). Besides for all of intensive purposes you can use Mono for nearly everything. If you are looking for pure multi-platform use Java. –  Ramhound Feb 15 '11 at 20:19
    
And if Microsoft doesn't extend .NET to other platforms, it will start to be less important on Windows too. We're a major commercial software vendor...over the past ~6 months, just about every new project has decided to use C++ because it's less risky. MS could remove a lot of that Uncertainly by supporting .NET on the Mac. –  Dan Feb 15 '11 at 20:33
add comment

You might find the MonoMac project useful - http://www.mono-project.com/MonoMac

It allows for developing Cocoa applications Mono style, which can be deployed to the Mac App store.

I would strongly consider this approach for a developer unfamiliar with Objective-C but with .NET/Mono/Java who has to deliver an application in a time restrained scenario.

share|improve this answer
add comment

None.

I recommend either writing a cross-compilable C++ application - may you have joy in it - or using Ruby with wxWidgets.

I consider .NET a bad proposition for cross-platform development and long-term product maintenance. Although, man, you can whiz out apps fast in it. :-/

Wish Delphi was still a major contender.

share|improve this answer
    
Ever heard of Lazarus? –  Happy Coder Jan 26 '13 at 13:03
add comment

If you want to run .NET natively on a Mac, you can use BootCamp to do this (i.e. you run Windows on the Mac, and your .NET applications in Windows).

If you meant Mac OS X rather than just the hardware, then you can use VMWare or Parallels to run the .NET applications in Windows (in emulation) in OS X. Both have visual modes that let your application appear as if it is running only within OS X (it will look and behave like a Windows application, but if you are writing a cross-platform non-web application without a custom interface for each OS you will always have that problem).

You will get the same amount of "support" by doing this, since you're running the app in Windows, albeit virtualized. Of course, anyone running the app will need a copy of the virtualization software, and Windows, and be willing to put up with an app that doesn't behave like an OS X app - but it is the only way to have "native" .NET running on a Mac.

share|improve this answer
add comment

Dan, I don't think you can do this. However, a possible solution (still vapourware) is to use Embarcadero Rad Studio C++ Builder, which has a nice VCL for developing visual applications (upon which much of .net is based), and they are RUMOURED to have cross-platform support coming out in the next release.

This will be develop on windows, target to Mac or Linux. Or so their roadmap says.

The C++ environment is reasonable and if you develop against the VCL then in theory the application will just work on the other platforms.

Of course until its actually shipped it remains to be seen how effective this really is.

share|improve this answer
add comment

The answer is no.

Actually your case seems to be a very good example of when not to choose .NET.

share|improve this answer
    
Nobody can predict the future and nobody wants to take on "undue" risk. –  Dan Feb 15 '11 at 19:43
    
@Dan: And the point is? You seem to be agreeing with me...? –  Gabriel Magana Feb 15 '11 at 19:47
add comment

If you want to develop for an OS then use the right tools. There are no truly professional apps written in mono for the Mac. There is on the other hand a lot of non-professional developers using a lot of tools creating a lot of garbage. Look at the mono app reviews that have been written for OSX. The developers are writing using an incomplete framework hacked to match the OSX platform. Start out write - if you have used C# Objective C is a quick learn.

Professional developers for the mac use C++, Objective C, Cocoa, and Xcode. I develop on several platforms and each has their own best tools. Use Xcode for the Mac and iOS.

Just as a side note Xcode is no Visual Studio it is not as stable and is a disgrace to apple in comparison, but it works well when you get used to he quirks. It is very difficult to beat Microsofts tools - but they were written for Windows not Linux, iOS, OSX, AIX etc.

share|improve this answer
    
Do you have any facts to backup statements like "Xcode is not as stable and is a disgrace to Apple" because based on my own personal experience everyone that has used Xcode has loved it. Besides even after you express your personal opinion on a subject it seems your not familar with, you are not even aware that in 2013, there actually is a solution. Of course the solution is actually Mono and Xamarin.Mac but it is a solution. The current version of Mono is nearly a 100% full implementation of .NET 4.0 it only lacks a couple major features which likely will never be ported ( i.e. WPF ). –  Ramhound Feb 1 '13 at 14:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.