Existe-t-il un moyen pris en charge pour exécuter des applications .NET 4.0 en mode natif sur un Mac?

Le cas échéant, quelles sont les options prises en charge par Microsoft pour exécuter le code C # /. NET 4.0 en mode natif sur Mac? Oui, je connais Mono, mais entre autres, il est en retard sur Microsoft. Et Silverlight ne fonctionne que dans un navigateur Web. Une solution de type VMWare ne suffira pas non plus.

Existe-t-il une réponse semi-officielle à la raison pour laquelle Microsoft ne prend tout simplement pas en charge .NET sur le Mac lui-même? Il semblerait qu'ils pourraient Silverlight et / ou acheter Mono et être rapidement là. Pas besoin de Visual Studio natif; la compilation croisée et le débogage à distance conviennent.

La raison en est que là où je travaille, il y a une incertitude croissante quant à l'avenir, ce qui entraîne beaucoup plus de développement à faire en C ++ au lieu de C #; de nouveaux projets choisissent d'utiliser C ++. Personne ne veut dire à la direction dans les 18 à 24 mois "désolé" si le Mac (ou l'iPad) devient une exigence. Le C ++ est considéré comme l'option la plus sûre, même si cela (sans doute) signifie une perte de productivité aujourd'hui.

Existe-t-il une réponse semi-officielle à la raison pour laquelle Microsoft ne prend tout simplement pas en charge .NET sur le Mac lui-même?

La meilleure réponse est probablement que vous ne "supportez" pas simplement .NET sur Mac. Vous dépensez des centaines de millions de dollars et plusieurs années à porter .NET sur Mac.

Bien que certaines choses soient entièrement gérées et ne nécessitent pas de portage, la plupart des choses sont des wrappers autour de l'API Win32 (fenêtres, contrôles, gdi +, cryptographie, Active Directory, COM, services d'entreprise, accès aux périphériques, son, vidéo, codecs, Winforms, etc.) etc).

Chacun d'eux devrait être résumé dans le backend et remappé vers des bibliothèques natives équivalentes sur OSX. Bien sûr, il n'y aura pas de bonne cartographie propre, vous devez donc également écrire des hacks sur des hacks pour qu'il fonctionne exactement de la même manière.

Ensuite, il y a le problème que ces API sur OSX peuvent être fragiles et Apple n'est pas très bon pour la compatibilité descendante, donc vous pouvez refaire vos hacks avec chaque version majeure (et parfois une version mineure et des correctifs), entraînant un coût de maintenance élevé.

Fondamentalement, c'est une énorme somme d'argent et cela fonctionne pour très peu de gain sur une plate-forme dont le propriétaire serait contre vous de le faire de toute façon. Et vous ne voulez pas vraiment dépenser de l'argent pour aider les gens à migrer de votre propre plateforme vers celle d'un concurrent.

Il vous reste donc des choix multiplateformes non parfaits:

• C ++, qui nécessitera toujours un portage à l'avenir
• Silverlight hors du navigateur, pour le support de Microsoft
• Mono, qui fait le travail pour prendre en charge un sous-ensemble sain de .NET, mais n'est pas Microsoft

Non, Silverlight est la seule option Microsoft de .Net sur OS X. Mono ne "traîne" pas autant que vous le pensez; il prend en charge .Net 4.0 et C # 4, par exemple. Cependant, les boîtes à outils de l'interface utilisateur (WinForms et WPF) ne sont pas bien prises en charge sous OS X. Mono ne prend pas du tout en charge WPF. Microsoft ne pourrait pas non plus réécrire l'intégralité du moteur de rendu. C'est probablement OK, cependant. Si vous souhaitez écrire une application Mac native, vous devez écrire une interface utilisateur native (peut-être en utilisant MonoMac).

Non. Mono est votre meilleur pari.

D'autres projets open source comme DotGNU peuvent également vous être utiles. http://www.gnu.org/software/dotgnu/ Mais rien de tout cela n'est pris en charge par MSFT.

Silverlight n'est pas uniquement un navigateur . Depuis que la version 3 OOB a existé et serait la voie que je prendrais si une plate-forme prise en charge par Microsoft est un must-have.

Bien que Mono puisse être décalé, il n'est pas aussi supprimé de la pile .NET que vous ne le pensez et ne doit pas être mis de côté comme une option viable.

Quant à savoir pourquoi Microsoft n'implémente pas la totalité de la pile .NET; ROI.

La plupart des bénéfices de Microsoft proviennent de deux produits - Windows et Office. La compatibilité multiplateforme nuirait à Windows.

Si vous voulez vraiment que le même code soit exécuté sur plusieurs plates-formes, écrivez une application Web. Cela ne vous ressemble cependant pas. «Juste au cas où» n'est pas une bonne raison, c'est un glissement de portée.

Même si vous décidez de cibler Mac OS X ou iOS dans 16 mois, pensez-vous vraiment que vous pourriez prendre votre code C ++ existant et le transformer en une bonne application native (ou même fonctionnelle)? À moins que vous ne travailliez sur un jeu en plein écran, la réponse est non.

Gagnez du temps avec C # maintenant, et si vous décidez de passer au Mac, réécrivez-le à la manière Mac avec Objective-C et Cocoa - vos utilisateurs vous remercieront.

Existe-t-il une réponse semi-officielle à la raison pour laquelle Microsoft ne prend tout simplement pas en charge .NET sur le Mac lui-même?

Où est le marché qui justifierait que les États-Unis dépensent le trésor pour le coder? Pour ce faire, ils devraient abandonner de sérieuses liquidités - des millions de dollars de salaire. Un processus continu, au fur et à mesure que des correctifs et des mises à jour arrivent.

Et pour quoi? Des droits de vantardise? Tout ce qu'ils en retirent, c'est la possibilité pour les utilisateurs d'abandonner Windows pour Apple et de continuer à exécuter leurs applications.

Si quelqu'un en profitait, ce serait Apple. Facilitez la transition des utilisateurs vers leur plateforme et les développeurs (DEVELOPERS DEVELOPERS) y codent. Mais pensez-vous que SJ donne une merde? Ils préfèrent inventer de nouvelles choses à coller un i Infront de. En outre, la plupart du cadre est OS et les spécifications CLR sont gratuites pour quiconque de les implémenter. Vous ne pouvez pas coller un NDA sale sur tout cela.

Vous pourriez trouver le projet MonoMac utile - http://www.mono-project.com/MonoMac

Il permet de développer des applications Cocoa de style Mono, qui peuvent être déployées sur le Mac App Store.

Je considérerais fortement cette approche pour un développeur peu familier avec Objective-C mais avec .NET / Mono / Java qui doit livrer une application dans un scénario limité dans le temps.

Aucun.

Je recommande soit d'écrire une application C ++ compilable de manière croisée - si vous en avez le plaisir - soit d'utiliser Ruby avec wxWidgets.

Je considère que .NET est une mauvaise proposition pour le développement multiplateforme et la maintenance à long terme des produits. Bien, mec, vous pouvez rapidement utiliser des applications. : - /

Souhait Delphi était toujours un concurrent majeur.

Si vous souhaitez exécuter .NET en mode natif sur un Mac, vous pouvez utiliser BootCamp pour ce faire (c'est-à-dire que vous exécutez Windows sur le Mac et vos applications .NET dans Windows).

Si vous vouliez dire Mac OS X plutôt que simplement le matériel, vous pouvez utiliser VMWare ou Parallels pour exécuter les applications .NET dans Windows (en émulation) sous OS X. Les deux ont des modes visuels qui permettent à votre application d'apparaître comme si elle s'exécutait uniquement dans OS X (il ressemblera et se comportera comme une application Windows, mais si vous écrivez une application non Web multiplateforme sans interface personnalisée pour chaque système d'exploitation, vous aurez toujours ce problème).

Vous obtiendrez la même quantité de "support" en faisant cela, puisque vous exécutez l'application dans Windows, bien que virtualisée. Bien sûr, toute personne exécutant l'application aura besoin d'une copie du logiciel de virtualisation et de Windows, et sera prête à accepter une application qui ne se comporte pas comme une application OS X - mais c'est le seul moyen d'avoir une "native" .NET fonctionnant sur un Mac.

Dan, je ne pense pas que tu puisses faire ça. Cependant, une solution possible (toujours vapourware) consiste à utiliser Embarcadero Rad Studio C ++ Builder, qui a une belle VCL pour développer des applications visuelles (sur lesquelles une grande partie de .net est basée), et ils sont RUMOURS d'avoir un support multiplateforme qui sortira dans la prochaine version.

Cela sera développé sur Windows, ciblé sur Mac ou Linux. C'est du moins ce que dit leur feuille de route.

L'environnement C ++ est raisonnable et si vous développez contre la VCL, en théorie, l'application ne fonctionnera que sur les autres plates-formes.

Bien sûr, jusqu'à ce qu'il soit réellement expédié, il reste à voir à quel point cela est vraiment efficace.

La réponse est non.

En fait, votre cas semble être un très bon exemple du moment de ne pas choisir .NET.

Si vous souhaitez développer pour un système d'exploitation, utilisez les bons outils. Il n'y a pas d'applications vraiment professionnelles écrites en mono pour le Mac. Il y a d'autre part beaucoup de développeurs non professionnels qui utilisent beaucoup d'outils créant beaucoup de déchets. Regardez les avis sur les applications mono qui ont été écrits pour OSX. Les développeurs écrivent en utilisant un framework incomplet piraté pour correspondre à la plateforme OSX. Commencez à écrire - si vous avez utilisé C #, l'objectif C est un apprentissage rapide.

Les développeurs professionnels pour Mac utilisent C ++, Objective C, Cocoa et Xcode. Je développe sur plusieurs plateformes et chacune a ses propres meilleurs outils. Utilisez Xcode pour Mac et iOS.

Tout comme une note latérale, Xcode n'est pas Visual Studio, il n'est pas aussi stable et est une honte pour Apple en comparaison, mais cela fonctionne bien lorsque vous vous habituez à ses caprices. Il est très difficile de battre les outils Microsofts - mais ils ont été écrits pour Windows et non Linux, iOS, OSX, AIX etc.