Macでネイティブに.NET 4.0アプリケーションを実行するためのサポートされている方法はありますか？
MacでネイティブにC＃/。NET 4.0コードを実行するためにMicrosoftがサポートしているオプションがある場合はどうなりますか？はい、私はMonoについて知っていますが、とりわけMicrosoftに遅れをとっています。また、SilverlightはWebブラウザーでのみ機能します。 VMWareタイプのソリューションもそれを削減しません。
MicrosoftがMac自体で.NETをサポートしていない理由について、半権威的な答えはありますか？ SilverlightやMonoを購入して、すぐに利用できるように思えます。ネイティブのVisual Studioは必要ありません。クロスコンパイルとリモートデバッグは問題ありません。
その理由は、私が仕事をしていると、将来についての不確実性が高まり、C＃ではなくC++でより多くの開発が行われるようになるためです。まったく新しいプロジェクトがC++の使用を選択しています。 Mac（またはiPad）が要件になったとしても、今から18〜24か月は "申し訳ありません"と誰も管理職に言いたくありません。 C++は、（おそらく）今日の生産性の低下を意味するとしても、より安全なオプションと見なされています。
microsoftがMac自体で.NETをサポートしていない理由について、半権威的な答えはありますか？
最良の答えは、おそらくMacで.NETを「サポートするだけ」ではないということです。あなたは数億ドルと数年かけて.NETをMacに移植しています。
一部は完全に管理されており、移植を必要としないものですが、ほとんどのものはWin32 API（ウィンドウ、コントロール、gdi +、暗号化、Active Directory、COM、エンタープライズサービス、デバイスアクセス、サウンド、ビデオ、コーデック、winformsなど）のラッパーです。等）。
これらすべてをバックエンドで抽象化し、OSX上の同等のネイティブライブラリに再マッピングする必要があります。もちろん、Niceクリーンマッピングはありません。そのため、ハックをまったく同じように機能させるには、ハックを作成する必要があります。
次に、OSX上のこれらのAPIが壊れやすくなる可能性があるという問題があります。Appleは下位互換性があまり良くないため、メジャーリリースごとにハッキングをやり直すことができます（マイナーリリースとホットフィックスが含まれる場合もあります）。 ）、高いメンテナンスコストをかけます。
基本的に、それは途方もない金額であり、とにかくそれを行うことに反対する所有者のプラットフォームではほとんど利益がありません。そして、あなたは本当に人々があなた自身のプラットフォームから競争相手に移住するのを助けるためにお金を使いたくありません。
したがって、完全ではないクロスプラットフォームの選択肢が残ります。
- C++。将来的にも移植が必要になります
- Microsoftサポートのために、ブラウザーからSilverlight
- .NETの健全なサブセットをサポートするために機能しますが、Microsoftではありません。
いいえ、Silverlightが唯一のMicrosoft OS X上の.Netのオプションです。Monoはあなたが思うほど「遅れ」ません。たとえば、.Net 4.0とC＃4をサポートしています。ただし、UIツールキット（WinFormsおよびWPF）はOS Xでは十分にサポートされていません。MonoはWPFをまったくサポートしていません。 Microsoftも、レンダリングエンジン全体を書き直さなければなりませんでした。しかし、それはおそらく大丈夫です。ネイティブMacアプリを作成したい場合は、ネイティブUI（おそらくMonoMacを使用）を作成する必要があります。
いいえ。Monoが最善の策です。
DotGNUのような他のオープンソースプロジェクトも同様に役立ちます。 http://www.gnu.org/software/dotgnu/ ただし、これらはいずれもMSFTでサポートされていません。
Silverlightはブラウザーのみではありません。バージョン3以降 [〜＃〜] oob [〜＃〜] が存在し、Microsoftがサポートするプラットフォームが必須である場合に使用するルートになります。
Monoは遅れる可能性がありますが、考えられるほど.NETスタックから削除されるわけではないため、実行可能なオプションとして除外するべきではありません。
マイクロソフトが.NETスタック全体を実装していない理由について。 ROI。
Microsoftの利益のほとんどは、WindowsとOfficeの2つの製品から得られます。プラットフォーム間の互換性はWindowsに悪影響を及ぼします。
同じコードをクロスプラットフォームで実行したい場合は、Webアプリを作成してください。それはあなたのようには聞こえません。 「念のため」は正当な理由ではありませんが、スコープクリープです。
今から16か月後にMac OS XまたはiOSをターゲットにすることを決定した場合でも、既存のC++コードを使用して、それを優れた（または機能的な）ネイティブアプリに変えることができると本当に思いますか？フルスクリーンのゲームに取り組んでいない限り、答えはノーです。
今すぐC＃で時間を節約し、Macに移行する場合は、Objective-CとCocoaを使用してMacの方法で書き直してください。ユーザーから感謝されます。
microsoftがMac自体で.NETをサポートしていない理由について、半権威的な答えはありますか？
MSがそれをコーディングする宝物を使うことを正当化するであろう市場はどこですか？これを行うために、彼らは深刻な現金、何百万ドルもの給与を落とさなければならないでしょう。修正と更新が行われるときの進行中のプロセス。
そして何のために？自慢する権利？彼らがそれから得るすべては人々がAppleのためにWindowsを捨て、それでも彼らのアプリを走らせることができるようにする能力です。
もし誰かがこれから利益を得るなら、それはアップルだろう。人々がプラットフォームに簡単に移行できるようにし、開発者（DEVELOPERS DEVELOPERS）がそれをコーディングしやすくします。しかし、SJはがらくたを与えると思いますか？彼らはむしろiを前に付けるための新しいものを発明したいのです。さらに、ほとんどのフレームワークはOSであり、CLR仕様は誰でも自由に実装できます。汚いNDAのどれにも貼り付けることはできません。
Macで.NETをネイティブに実行する場合は、BootCampを使用してこれを実行できます（つまり、MacでWindowsを実行し、Windowsで.NETアプリケーションを実行します）。
ハードウェアだけでなくMac OS Xの場合は、VMWareまたはParallelsを使用して、OS XのWindowsで.NETアプリケーションを（エミュレーションで）実行できます。どちらにも、アプリケーションが実行しているように見えるようにするビジュアルモードがあります。 OS X内（Windowsアプリケーションのように見え、動作しますが、各OSのカスタムインターフェイスなしでクロスプラットフォームの非Webアプリケーションを作成している場合、常にその問題が発生します）。
仮想化されているにもかかわらず、Windowsでアプリを実行しているため、これを行うことで同じ量の「サポート」が得られます。もちろん、アプリを実行している人は誰でも仮想化ソフトウェアのコピーとWindowsが必要であり、OS Xアプリのように動作しないアプリに我慢して進んでいきますが、これは「ネイティブ」にする唯一の方法ですMacで実行されている.NET。
ダン、これはできないと思います。ただし、可能なソリューション（まだ蒸気プログラム）は、ビジュアルアプリケーション（.netの大部分に基づいている）を開発するためのNice VCLを備えたEmbarcadero Rad Studio C++ Builderを使用することです。次のリリースで。
これはWindowsで開発され、MacまたはLinuxをターゲットにします。または彼らのロードマップは言う。
C++環境は妥当であり、VCLを使用して開発する場合、理論的にはアプリケーションは他のプラットフォームで動作します。
もちろん、実際に出荷されるまでは、これが実際にどれほど効果的であるかは不明です。
MonoMacプロジェクトは便利かもしれません- http://www.mono-project.com/MonoMac
Mac App Storeに展開できるCocoaアプリケーションMonoスタイルの開発を可能にします。
私は、Objective-Cに不慣れであるが、時間の制約があるシナリオでアプリケーションを提供する必要がある.NET/Mono/Javaに不慣れな開発者に対して、このアプローチを強く検討します。
なし。
私はクロスコンパイル可能なC++アプリケーションを書くことをお勧めします-あなたがそれに喜びを持っているかもしれません-またはwxWidgetsでRubyを使用します。
私は.NETをクロスプラットフォーム開発と長期的な製品保守のための悪い命題だと考えています。ただし、アプリをすばやく実行することはできます。 ：-/
ウィルデルファイは依然として主要な候補でした。