20

C# (and the .NET platform in general) is looking like it's becoming a good option form multi-targeting applications:

  • official Microsoft .NET framework: full-blow Windows development, ASP.NET development, Windows Phone development, etc.

  • Mono and all its derivatives: MonoTouch, MonoDroid: the rest of the world. These tools are today RTM.

  • Does it mean that C# is becoming a good language for targeting the most popular platforms, desktop, web, and mobile?

  • Is it still better to use the "native" language of target platforms (Objective-C, Java, etc.)

  • Is it only a screen of smoke and only marketing language?

Please note that I'm actually conscious I won't able to copy/paste the code between platforms. But I'm sure the lower layers of applications (models, business, etc.) can be reused, but I know I'll have to adapt the higher layers (GUI, etc.) to the platform. My goal is more focused on required skills than technical code sharing.

I am a C# developer in a company that massively uses C#. That's why I talked about C# in a plan to expand the range of target platforms in my company.

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
Steve B
  • 353
  • 3
  • 10

2 Answers2

14

Yes, in general, the .NET Framework is great for apps that target a broad range of devices. But this isn't unique to .NET; Java was doing that long before. The thing to keep in mind is that there's no real alternative to the native tools for a particular platform.

The Mac applications that you create with .NET will never look like native Mac OS X applications, and that's considered a problem by the vast majority of OS X users. That may not be important to you strategically, depending on whether your business model values maximizing saturation over maximizing user satisfaction, but it's certainly something to keep in mind when making a choice.

The GUI systems in Linux and Windows are somewhat more flexible in terms of which applications look "native" and fit in well with the platform. But I blame that mainly on the lack of clear interface guidelines and the fact that application developers have historically been willing to ignore the ones that do exist. Many Mac users prefer the Mac precisely because of its consistent user interface.

Considering that you'll have to adapt the GUI layer to the specific platform (and possibly rewrite it in a different language entirely, such as Objective-C), that leaves you leveraging the .NET platform only for library code. And then there's not a very clear win for C# over C++, in my opinion.

For rapid application development, there are few alternatives that are better than C# and .NET. And pushing an app out quickly and having it immediately available on a diversity of platforms is certainly a business advantage. But for true multi-platform applications that aim to truly satisfy the user, it's not necessarily the silver bullet solution.

Cody Gray - on strike
  • 1,737
  • 2
  • 19
  • 22
  • 10
    "The Mac applications that you create with .NET will never look like native Mac OS X applications,...". Let me introduce you to MonoMac: http://www.mono-project.com/MonoMac –  May 09 '11 at 10:57
  • 3
    @Dimitris: Let's just say I'm skeptical, at best. The Qt folks tried this, and people still jump up and down about their having achieved it. They're wrong: they haven't. Qt applications do *not* look like native OS X applications. They're just...wrong. I don't see any screenshots in the link you suggested, but even if they get the UI perfect, they'll still be missing all of the behavior and implementation details. Thanks for the reference, though. It's something to be optimistic about. – Cody Gray - on strike May 09 '11 at 10:59
  • 7
    @Cody Gray: MonoMac looks and acts native because it's not a cross platform API, but instead natively wraps the underlying Cocoa API. It looks and acts native because it IS native. –  May 09 '11 at 11:11
  • @jonp: Oh, really? Wow... That's actually onto something. Thanks for the clarification. – Cody Gray - on strike May 09 '11 at 11:13
  • 1
    @Cody Gray: MonoMac is to Mac what MonoTouch is to iOS. You can write native apps, you just use C# instead of Obj-C. It is not "make WinForms or Gtk look good on Mac". –  May 09 '11 at 11:50
  • @Cody Gray: thanks for this interesting feedback. If you add in the equation that c# is well mastered by developers today, what can be the options ? 1. use C# and rely on mono* ? 2. introduce native (by native I mean "official" language, not processor native) code for very specific tasks (either low-level or GUI), and share c# code where it's feasible ? 3. keep c# on MS platform (windows phone, windows apps and server side), and move fully to native dev on other platforms. I'm starting to think the 3rd option is the less risky in the long term, but with a higher starting cost. – Steve B May 10 '11 at 07:31
  • @Steve: It all depends on what your specific targets are, and what *technologies* within the .NET Framework that your developers know. WPF won't do you a whole lot of good when it comes to desktop applications running on Mono, for example. If it were me, I'd pick option 3. As I mentioned, I just don't see the advantage of writing reusable library code for multiple platforms in C#. Why not just write in C++? The dependency on the .NET Framework is a hindrance, rather than a benefit, unless you can point to specific features of it that you're taking advantage of. – Cody Gray - on strike May 10 '11 at 07:54
  • But it's really hard to give *generic* advice. You have to make a decision based on your specific situation and what you hope to ultimately accomplish. I don't think I can make that decision for anyone else but myself. – Cody Gray - on strike May 10 '11 at 07:55
  • @Cody gray: c++ is not an option as WP7 only allows C# as programming language. What I want to share ? Mainly some "model" and "business" classes. Model, because a customer will always have an ID property, a Title property, etc. And business because the title of the customer will always be validated with same rules, and because the computation of the estimated revenue with this customer will always follow the same algorithm. This is only an example, but it shows there is, in my opinion, no dependency with any target platform. In all case thanks a lot. It add to my reflexion some thinks to cons – Steve B May 10 '11 at 08:01
  • @Steve: Oh, does it? See, and that's my point. I know *nothing* about Windows Phone development. I don't have a Windows phone, I wouldn't ever *own* a Windows phone, and I don't plan on getting into Windows phone development. There are just too many specifics here to give a generic, one-size-fits-all answer. What works for one company won't work for another. You just have to be aware of the limitations of the various technologies and try to make the best decision that you can. My answer was more intended to give you something to think about than to suggest a business philosophy. – Cody Gray - on strike May 10 '11 at 08:05
  • @cody gray: and you reach your goal :) – Steve B May 10 '11 at 08:07
  • 1
    @jonp: So MonoMac isn't good for a write once/run everywhere sort of Holy Grail? And it does produce applications an avid Mac user will accept? – David Thornley May 10 '11 at 16:00
  • 3
    Just wanted to chip-in on the conversation above since I am right in the middle of building a system that spans iPad & Windows Phone, ASP.NET MVC3 and NT Services interfacing with a robotics control system. Mono, MonoDroid, MonoTouch, etc., as Cody pointed out above, is a way to write code in C# that allows you to take advantage of the power of C# and the .NET Framework (including Linq) whilst also enjoying unfettered access to your chosen platform's "native" API's ... whilst also avoiding the many memory management issues inherent to most native C/C++/ObjC code. – Richard Turner May 10 '11 at 22:01
2

I use C# on games running on Xbox and Windows machines, I use it in Compact Framework applications for robotics solutions, I use MonoTouch for iPad development, I have some web applications running on Linux and few other solutions.

Usually there is a way how to do your thing on a given platform. The core layer is about the same for most of them (case study needed indeed). The problem - and I consider it as a serious one - is the development environment. I am used to Visual Studio and its features. But MonoDevelop, for example, drives me nuts.

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
scarlaxx
  • 21
  • 1