Gibt es eine unterstützte Möglichkeit, .NET 4.0-Anwendungen nativ auf einem Mac auszuführen?

11

Welche Optionen werden von Microsoft unterstützt, um C # /. NET 4.0-Code nativ auf dem Mac auszuführen? Ja, ich weiß über Mono Bescheid, aber unter anderem bleibt es Microsoft hinterher. Und Silverlight funktioniert nur in einem Webbrowser. Eine VMWare-Lösung wird es auch nicht schaffen.

Gibt es eine halbautorisierende Antwort darauf, warum Microsoft .NET auf dem Mac selbst einfach nicht unterstützt? Es scheint, als könnten sie Silverlight und / oder Mono kaufen und schnell da sein. Kein natives Visual Studio erforderlich; Cross-Compiling und Remote-Debugging sind in Ordnung.

Der Grund dafür ist, dass bei meiner Arbeit die Unsicherheit über die Zukunft zunimmt, was dazu führt, dass in C ++ viel mehr Entwicklungen als in C # durchgeführt werden. Brandneue Projekte entscheiden sich für C ++. Niemand möchte dem Management in 18 bis 24 Monaten "Entschuldigung" sagen, falls der Mac (oder das iPad) zur Anforderung wird. C ++ wird als sicherere Option angesehen, auch wenn dies (wohl) heute einen Produktivitätsverlust bedeutet.

c# .net mac mono

— Nаn
quelle

2

Von wem unterstützt?

Warum interessiert es Sie eigentlich, wenn MS dies unterstützt? IMO sollte es wichtiger sein, wenn Apple es unterstützt, wenn Sie auf Mac abzielen möchten.

— Alternative

Mit C ++ zu arbeiten ist keine schlechte Idee. Sie können eine tragbare Codebasis haben und die nativen GUIs auf jeder Plattform verwenden.

— Mike30

1

Um diesen Beitrag zu aktualisieren, hat MS anscheinend davon Kenntnis genommen und wird .NET auf verschiedenen Betriebssystemen unterstützen, obwohl nicht klar ist, wie dies geschehen soll. Sie können plattformübergreifende Anwendungen mit .NET mithilfe von NOV erstellen : nevron.com/products-open-vision.aspx (ich arbeite für dieses Unternehmen). Im Allgemeinen können Sie unter Windows in C # codieren und dann für Wpf, MAC, Silverlight und bald auch für iOS und Android kompilieren. Es gibt eine kostenlose (Community-) Edition dieses Produkts, sodass Sie nicht auf Produktivität verzichten und sich an arkanes C ++ halten müssen.

— Bob Milanov

17

Gibt es eine halbautorisierende Antwort darauf, warum Microsoft .NET auf dem Mac selbst einfach nicht unterstützt?

Die beste Antwort ist wahrscheinlich, dass Sie .NET auf dem Mac nicht "nur unterstützen". Sie verbringen Hunderte Millionen Dollar und mehrere Jahre damit, .NET auf den Mac zu portieren.

Während einige Dinge vollständig verwaltet werden und keine Portierung erfordern würden, sind die meisten Dinge Wrapper um die Win32-API (Fenster, Steuerelemente, GDI +, Kryptografie, Active Directory, COM, Unternehmensdienste, Gerätezugriff, Sound, Video, Codecs, Winforms usw.) usw).

Jedes einzelne davon müsste im Backend abstrahiert und unter OSX äquivalenten nativen Bibliotheken neu zugeordnet werden. Natürlich wird es kein schönes, sauberes Mapping geben, also müssen Sie auch Hacks über Hacks schreiben, damit es genauso funktioniert.

Dann gibt es das Problem, dass diese APIs unter OSX spröde sein können und Apple die Abwärtskompatibilität nicht sehr gut beherrscht, sodass Sie Ihre Hacks bei jeder Hauptversion (und manchmal bei kleineren Versionen und Hotfixes) wiederholen können, was hohe Wartungskosten verursacht.

Grundsätzlich ist es eine enorme Menge an Geld und Arbeit für sehr wenig Gewinn auf einer Plattform, deren Besitzer sowieso dagegen wäre, dass Sie es tun. Und Sie möchten nicht wirklich Geld ausgeben, um Menschen dabei zu helfen, von Ihrer eigenen Plattform auf die eines Konkurrenten zu migrieren.

Sie haben also nicht die perfekte plattformübergreifende Auswahl:

C ++, das auch in Zukunft portiert werden muss
Silverlight aus dem Browser für Microsoft-Unterstützung
Mono, das die Arbeit zur Unterstützung einer fehlerfreien Teilmenge von .NET erledigt, jedoch nicht Microsoft

— jpobst
quelle

5

You spend hundreds of millions of dollars and several years porting .NET to the Mac.Entschuldigen Sie mich? Diese Zahl klingt etwas hoch ... Ich bin mir ziemlich sicher, dass das Mono-Framework (mit Unterstützung für viele weitere Betriebssysteme) nicht so viel gekostet hat.

— Bobby

1

@ Bobby: das denke ich mir. Mono + Silverlight scheint den größten Teil des Weges dorthin zu sein. Fügen Sie dazu etwas P / Invoke und / oder C ++ / CLI für weniger Mainstream-Inhalte (Kryptografie, AD usw.) hinzu, und ich denke, Sie hätten eine ziemlich vernünftige Lösung zu vernünftigen Kosten. Mein Argument ist, dass Microsoft Geld ausgeben möchte, um Menschen beim Einstieg in OSX zu helfen. Wenn dies nicht der Fall ist, wird C # /. NET unter Windows nicht mehr verwendet.

— Am

@Dan: Genau, Microsoft möchte nicht mit der Welt kompatibel sein, sonst könnte die Welt etwas anderes gebrauchen. ;)

— Bobby

15

Das Mono-Framework ist auch keine vollständige, vollständig getestete, dokumentierte und unterstützte Lösung. Es gibt einen Unterschied darin, was für Open Source "gut genug" ist und welche Qualität die Leute von Microsoft erwarten. Es würde leicht Hunderte Millionen Dollar kosten, wenn sie es auf das Niveau bringen würden, das Benutzer verlangen würden. Was sie tun könnten, um die Investition zu verringern, wäre, eine beliebte (und tragbare) Teilmenge des .NET-Frameworks auszuwählen und es einfach zu tun. Das haben sie beschlossen, sie nennen es "Silverlight".

— Jpobst

@jpobst, aber es sieht so aus, als hätte MS genau das getan ... und mehr?

— Am

14

Nein, Silverlight ist die einzige Microsoft- Option von .Net unter OS X. Mono "verzögert" sich nicht so stark, wie Sie denken. Es unterstützt beispielsweise .NET 4.0 und C # 4. Die UI-Toolkits (WinForms und WPF) werden unter OS X jedoch nicht gut unterstützt. Mono unterstützt WPF überhaupt nicht. Microsoft konnte es auch nicht, ohne die gesamte Rendering-Engine neu zu schreiben. Das ist aber wahrscheinlich in Ordnung. Wenn Sie eine native Mac-App schreiben möchten, sollten Sie eine native Benutzeroberfläche schreiben (möglicherweise mit MonoMac).

— Barry Wark
quelle

Das Management scheint nicht sehr geneigt zu sein, sich der Mono-Option anzuschließen. Und .NET 4.0 wurde am selben Tag wie unter Windows (oder?) Sicher nicht unterstützt.

— Am

Ist Silverlight an der WPF-Front (schon) nicht schon den größten Teil des Weges dorthin? Ja, die XAML muss anders sein, um ein Mac-Erscheinungsbild zu erhalten.

— Am

2

@Dan: So wie sich Mono heutzutage bewegt, wenn Sie mit der Entwicklung einer App für die neueste Version von .NET beginnen, wenn Microsoft sie veröffentlicht, wird Mono dieselbe Version unterstützen, sobald diese App versandbereit ist.

— Anon.

@Dan SL und WPF unter dem Deckmantel versuchen, so viel wie möglich zusammenzuführen. Es gibt technische Unterschiede, aber die grundlegenden Konzepte sind plattformübergreifend.

— Aaron McIver

6

Wenn Ihr Unternehmensmanagement nicht bereit ist, Mono zu verwenden, können Sie eine in herkömmlichem C # 4.0 geschriebene Desktop-Anwendung nicht so einfach erstellen.

— Ramhound

5

Mono ist deine beste Wahl.

Andere Open-Source-Projekte wie DotGNU können Ihnen ebenfalls dienen. http://www.gnu.org/software/dotgnu/ Aber keines davon wird von MSFT unterstützt.

— Ishpeck
quelle

4

Silverlight ist nicht nur ein Browser . Da Version 3 OOB existiert und der Weg wäre, den ich einschlagen würde, wenn eine von Microsoft unterstützte Plattform ein Muss ist.

Obwohl Mono möglicherweise verzögert ist, wird es nicht so aus dem .NET-Stapel entfernt, wie Sie vielleicht denken, und sollte nicht als praktikable Option beiseite geworfen werden.

Warum implementiert Microsoft nicht den gesamten .NET-Stack? ROI.

— Aaron McIver
quelle

Aber es scheint, als wären sie Silverlight so nahe ... warum nicht einfach den Job beenden? Das scheint für alle so viel besser zu sein, als dass Mono den Compiler, die CLR usw.

— rückentwickelt

1

SL ist nicht der gesamte .NET-Stack. Die SL-Laufzeit im Vergleich zum gesamten .NET-Stack sind völlig unterschiedliche Tiere.

— Aaron McIver

Ja, aber da kann man schon Dinge wie OOB tun , wie Sie mit SL vorschlagen, warum nicht Port den Rest (1/3? 40%?) Des .NET - Stack? Oder ist SL wirklich nichts anderes als ein Versuch, Flash zu töten?

— Am

@Dan Wenn Unternehmen Dinge in die Cloud verschieben ... ist das Letzte, was Sie tun möchten, einen Stapel zu portieren, der nicht in der Cloud ausgeführt werden kann. SL kann über mehrere Browser ausgeführt werden. Sie können mit Leuten wie Google und anderen argumentieren, dass der Drang, in einem Browser zu arbeiten, real ist. Warum würden Sie sich dann in diesem Moment dafür entscheiden, einen ganzen Stack auf ein Betriebssystem mit einem Marktanteil von <10% zu portieren, zusammen mit der heutzutage so weit verbreiteten Virtualisierung?

— Aaron McIver

Microsoft hat (wohl) die beste derzeit verfügbare Entwicklungsumgebung mit C # und .NET. Aber Unternehmen wie ich werden sich aufgrund der Unsicherheit in Bezug auf Mac / iPad / Cloud / etc. Zunehmend davor scheuen. C ++ scheint viel sicherer zu sein.

— Am

3

Der größte Teil des Gewinns von Microsoft stammt aus zwei Produkten - Windows und Office. Plattformübergreifende Kompatibilität würde Windows schaden.

Wenn Sie wirklich möchten, dass derselbe Code plattformübergreifend ausgeführt wird, schreiben Sie eine Web-App. Es klingt aber nicht so wie du. "Nur für den Fall" ist kein guter Grund, es ist Scope Creep.

Selbst wenn Sie sich in 16 Monaten für Mac OS X oder iOS entscheiden, glauben Sie wirklich, Sie könnten Ihren vorhandenen C ++ - Code in eine gute (oder sogar funktionale) native App verwandeln? Wenn Sie nicht an einem Vollbildspiel arbeiten, lautet die Antwort Nein.

Sparen Sie jetzt Zeit mit C #, und wenn Sie sich entscheiden, auf den Mac zu wechseln, schreiben Sie ihn mit Objective-C und Cocoa auf Mac-Weise neu - Ihre Benutzer werden es Ihnen danken.

— Tobias Cohen
quelle

1

"Nur für den Fall" ist die Realität; Niemand möchte dem Management "oops" sagen, wenn es in C ++ eine sicherere Option gibt.

— Am

1

Vorausgesetzt, der Schnittstellencode ist ordnungsgemäß getrennt, ist es einfacher, C ++ - Code auf den Mac zu verschieben. Schreiben Sie die Benutzeroberfläche in Objective-C mit Cocoa neu, verknüpfen Sie sie mit dem Rest, und Sie haben eine Menge Arbeit erledigt.

— David Thornley

@ David: und daher das Problem hinter dieser Frage: mehr C ++, (viel) weniger C #. Ich mag (wirklich) C #!

— Am

Diese plattformübergreifenden Bedenken hier sind der Grund, warum viele von uns immer noch Java verwenden und nicht zu C # wechseln.

— Brian Knoblauch

1

Gibt es eine halbautorisierende Antwort darauf, warum Microsoft .NET auf dem Mac selbst einfach nicht unterstützt?

Wo ist der Markt, der es rechtfertigen würde, dass MS den Schatz ausgibt, der ihn codiert? Um dies zu tun, müssten sie ernsthaftes Geld fallen lassen - Millionen von Dollar Gehalt. Ein fortlaufender Prozess, da Korrekturen und Updates folgen.

Und wofür? Rechte prahlen? Alles, was sie daraus machen, ist die Möglichkeit für Benutzer, Windows für Apple aufzugeben und ihre Apps weiterhin ausführen zu können.

Wenn jemand davon profitieren würde, wäre es Apple. Erleichtern Sie den Benutzern den Übergang zu ihrer Plattform und den Entwicklern (DEVELOPERS DEVELOPERS) das Codieren darauf. Aber denkst du, SJ macht einen Mist? Sie würden lieber neue Sachen erfinden einen Stick i von Infront. Außerdem ist der größte Teil des Frameworks das Betriebssystem und die CLR-Spezifikationen können von jedermann kostenlos implementiert werden. Sie können keine schmutzige NDA auf irgendetwas davon kleben.

— Abgerissen
quelle

Ein Teil von "Was für Microsoft drin ist" besteht darin, die Benutzer dazu zu bringen, ihre erstklassigen Tools unter Windows zu verwenden. So wie die Dinge hier laufen, wird C # /. NET in interne Apps verbannt. Entwickler, die C # seit Jahren verwenden, schreiben wieder C ++. Wie für die Kosten; es scheint, als wären sie dort bereits mit Silverlight und / oder Mono zu 2/3.

— Am

Mono ist eine Open Source-Plattform, und während die Quelle für .NET veröffentlicht wurde, ist .NET Framework NICHT Open Source. Microsoft wird Mono aus vielen Gründen nicht kaufen können. Der Hauptgrund ist, dass es keine einzige 100% Open Source-Anwendung gibt. Wissen Sie, dass Silverlight nur eine einzige Sprache in .NET ist und dass es plattformübergreifend ist, weil Microsoft möchte, dass es Flash ersetzt. Ich sollte auch hinzufügen, dass Apple Handbewegungen gemacht hat, um nicht einmal etwas auf seinem Betriebssystem zuzulassen.

— Ramhound

1

@Dan klingt so, als ob die Lösung für Ihre Probleme nicht "eine Sprache, um sie alle zu regieren" ist, sondern "Wie werden wir plattformunabhängig bereitgestellt?". Die meisten Leute erreichen dies, indem sie die Benutzeroberfläche aus der Logik herausbrechen und eine pro Plattform und die andere als Service in die Innertubes einbetten.

— Ripped Off

1

@ Dan Ich habe eine Lösung dafür ... Codieren Sie nicht für den Mac. Ich habe eine persönliche Vereinbarung, die ich nicht für Apple entwickelt und selbst geschrieben habe. Ich würde es absolut hassen, C # nicht codieren zu können, und dies daher vermeiden. Aber manchmal musst du tun, was du tun musst, und wenn Wünsche Fische wären, müssten wir uns eine andere Alliteration ausdenken, um die vielen Dinge zu beschreiben, die wir wollen, aber nicht haben können.

— Abgerissen

1

@ Dan kindasorta. Sie haben den Desktop (noch) nicht wirklich berührt. Aber ich bin erstaunt, welchen Unterschied fünf Jahre machen.

— Abgerissen

0

Das MonoMac-Projekt ist möglicherweise hilfreich - http://www.mono-project.com/MonoMac

Es ermöglicht die Entwicklung von Cocoa-Anwendungen im Mono-Stil, die im Mac App Store bereitgestellt werden können.

Ich würde diesen Ansatz für einen Entwickler in Betracht ziehen, der mit Objective-C nicht vertraut ist, aber mit .NET / Mono / Java, der eine Anwendung in einem zeitlich begrenzten Szenario bereitstellen muss.

0

Keiner.

Ich empfehle, entweder eine überkompilierbare C ++ - Anwendung zu schreiben - mögen Sie Freude daran haben - oder Ruby mit wxWidgets zu verwenden.

Ich halte .NET für ein schlechtes Angebot für die plattformübergreifende Entwicklung und die langfristige Produktwartung. Obwohl, Mann, können Sie Apps darin schnell heraussuchen. : - /

Ich wünschte, Delphi wäre immer noch ein Hauptkonkurrent.

— Paul Nathan
quelle

1

Schon mal was von Lazarus gehört?

— Happy Coder

Auch jemals Leiter von Java?

— Fernando Gonzalez Sanchez

0

Wenn Sie .NET nativ auf einem Mac ausführen möchten, können Sie dazu BootCamp verwenden (dh Sie führen Windows auf dem Mac und Ihre .NET-Anwendungen unter Windows aus).

Wenn Sie Mac OS X und nicht nur die Hardware gemeint haben, können Sie VMWare oder Parallels verwenden, um die .NET-Anwendungen unter Windows (in Emulation) unter OS X auszuführen. Beide verfügen über visuelle Modi, mit denen Ihre Anwendung so angezeigt wird, als würde sie nur ausgeführt innerhalb von OS X (es sieht aus und verhält sich wie eine Windows-Anwendung, aber wenn Sie eine plattformübergreifende Nicht-Webanwendung ohne benutzerdefinierte Oberfläche für jedes Betriebssystem schreiben, tritt dieses Problem immer auf).

Auf diese Weise erhalten Sie die gleiche Menge an "Support", da Sie die App unter Windows ausführen, obwohl sie virtualisiert ist. Natürlich benötigt jeder, der die App ausführt, eine Kopie der Virtualisierungssoftware und von Windows und ist bereit, eine App zu akzeptieren, die sich nicht wie eine OS X-App verhält - aber es ist die einzige Möglichkeit, "native" zu haben. .NET läuft auf einem Mac.

— Tony Meyer
quelle

0

Dan, ich glaube nicht, dass du das kannst. Eine mögliche Lösung (immer noch Vapourware) ist jedoch die Verwendung von Embarcadero Rad Studio C ++ Builder, das über eine schöne VCL für die Entwicklung visueller Anwendungen verfügt (auf denen ein Großteil von .net basiert), und es wird gemunkelt, dass plattformübergreifende Unterstützung herauskommt in der nächsten Version.

Dies wird unter Windows entwickelt und auf Mac oder Linux ausgerichtet. Zumindest heißt es in ihrer Roadmap.

Die C ++ - Umgebung ist vernünftig und wenn Sie gegen die VCL entwickeln, funktioniert die Anwendung theoretisch nur auf den anderen Plattformen.

Natürlich bleibt abzuwarten, wie effektiv dies wirklich ist, bis es tatsächlich ausgeliefert wird.

— schnell_now
quelle

-2

Die Antwort ist nein.

Tatsächlich scheint Ihr Fall ein sehr gutes Beispiel dafür zu sein, wann Sie sich nicht für .NET entscheiden sollten.

— Gabriel Magana
quelle

Niemand kann die Zukunft vorhersagen und niemand will ein "unangemessenes" Risiko eingehen.

— Am

@ Dan: Und der Punkt ist? Sie scheinen mir zuzustimmen ...?

— Gabriel Magana

-3

Wenn Sie für ein Betriebssystem entwickeln möchten, verwenden Sie die richtigen Tools. Es gibt keine wirklich professionellen Apps, die in Mono für den Mac geschrieben wurden. Auf der anderen Seite verwenden viele nicht professionelle Entwickler viele Tools, die viel Müll erzeugen. Schauen Sie sich die Mono-App-Bewertungen an, die für OSX geschrieben wurden. Die Entwickler schreiben mit einem unvollständigen Framework, das gehackt wurde, um mit der OSX-Plattform übereinzustimmen. Beginnen Sie mit dem Schreiben - wenn Sie C # verwendet haben, ist Ziel C ein schnelles Lernen.

Professionelle Entwickler für den Mac verwenden C ++, Objective C, Cocoa und Xcode. Ich entwickle auf mehreren Plattformen und jede hat ihre eigenen besten Werkzeuge. Verwenden Sie Xcode für Mac und iOS.

Genau wie eine Randnotiz ist Xcode kein Visual Studio, es ist nicht so stabil und eine Schande für Apple im Vergleich, aber es funktioniert gut, wenn man sich an die Macken gewöhnt. Es ist sehr schwierig, Microsoft-Tools zu schlagen - aber sie wurden für Windows geschrieben, nicht für Linux, iOS, OSX, AIX usw.

— Dr. Maynord
quelle

1

Haben Sie Fakten zu Backup-Aussagen wie "Xcode ist nicht so stabil und ist eine Schande für Apple", weil aufgrund meiner persönlichen Erfahrung jeder, der Xcode verwendet hat, es geliebt hat. Selbst wenn Sie Ihre persönliche Meinung zu einem Thema äußern, mit dem Sie nicht vertraut zu sein scheinen, wissen Sie nicht einmal, dass es 2013 tatsächlich eine Lösung gibt. Natürlich ist die Lösung tatsächlich Monound Xamarin.Macaber es ist eine Lösung. Die aktuelle Version von Mono ist eine fast 100% vollständige Implementierung von .NET 4.0. Es fehlen nur einige wichtige Funktionen, die wahrscheinlich nie portiert werden (z. B. WPF).

— Ramhound