Czy istnieje obsługiwany sposób uruchamiania aplikacji .NET 4.0 natywnie na komputerze Mac?

Jakie, jeśli w ogóle, są obsługiwane przez Microsoft opcje uruchamiania kodu C # / .NET 4.0 natywnie na komputerze Mac? Tak, wiem o Mono, ale między innymi opóźnia Microsoft. Silverlight działa tylko w przeglądarce internetowej. Rozwiązanie typu VMWare też go nie uciszy.

Czy jest jakaś autorytatywna odpowiedź na pytanie, dlaczego Microsoft po prostu nie obsługuje platformy .NET na samym komputerze Mac? Wygląda na to, że mogliby Silverlight i / lub kupić Mono i szybko tam być. Nie ma potrzeby rodzimego programu Visual Studio; kompilacja krzyżowa i zdalne debugowanie są w porządku.

Powodem jest to, że tam, gdzie pracuję, rośnie niepewność co do przyszłości, co powoduje, że w C ++ jest dużo więcej prac rozwojowych niż w C #; zupełnie nowe projekty wybierają C ++. Nikt nie chce powiedzieć zarządowi za 18–24 miesięcy „przepraszam”, jeśli Mac (lub iPad) stanie się wymaganiem. C ++ jest postrzegana jako bezpieczniejsza opcja, nawet jeśli (prawdopodobnie) oznacza dzisiaj spadek wydajności.

czy jest jakaś autorytatywna odpowiedź na pytanie, dlaczego Microsoft po prostu nie obsługuje platformy .NET na samym komputerze Mac?

Najlepszą odpowiedzią jest prawdopodobnie to, że nie tylko „obsługuje” .NET na komputerze Mac. Wydajesz setki milionów dolarów i kilka lat na przenoszenie platformy .NET na komputer Mac.

Podczas gdy niektóre rzeczy są w pełni zarządzane i nie wymagałyby przenoszenia, większość rzeczy jest owijkami wokół Win32 API (Windows, formanty, gdi +, kryptografia, active directory, COM, usługi dla przedsiębiorstw, dostęp do urządzeń, dźwięk, wideo, kodeki, winforms itp. itp).

Każda z nich musiałaby zostać wyodrębniona w backendie i odwzorowana na równoważne rodzime biblioteki w OSX. Oczywiście nie będzie ładnego czystego mapowania, więc musisz również pisać hacki po hackach, aby działał dokładnie tak samo.

Potem jest problem, że te interfejsy API w OSX mogą być kruche, a Apple nie jest zbyt dobry w kompatybilności wstecznej, więc możesz powtarzać swoje hacki z każdą większą wersją (a czasem drobną wersją i poprawkami), co podnosi wysokie koszty utrzymania.

Zasadniczo jest to ogromna ilość pieniędzy i praca za bardzo mały zysk na platformie, której właściciel i tak byłby przeciwko tobie. I tak naprawdę nie chcesz wydawać pieniędzy, aby pomóc ludziom w migracji z własnej platformy na platformę konkurencji.

Pozostaje Ci więc niezbyt doskonały wybór między platformami:

• C ++, który nadal będzie wymagał przeniesienia w przyszłości
• Silverlight z przeglądarki, do obsługi Microsoft
• Mono, który działa w celu obsługi zdrowego podzbioru platformy .NET, ale nie jest Microsoft

Nie, Silverlight jest jedyną opcją Microsoft od .Net na OS X. Mono nie „opóźnia” się tak bardzo, jak myślisz; obsługuje na przykład .Net 4.0 i C # 4. Jednak zestawy narzędzi interfejsu użytkownika (WinForms i WPF) nie są dobrze obsługiwane w systemie OS X. Mono w ogóle nie obsługuje WPF. Microsoft także nie mógł przepisać całego silnika renderującego. Ale to chyba OK. Jeśli chcesz napisać natywną aplikację Mac, powinieneś pisać natywny interfejs użytkownika (być może za pomocą MonoMac).

Nie. Mono to twój najlepszy zakład.

Inne projekty open source, takie jak DotGNU, również mogą ci służyć. http://www.gnu.org/software/dotgnu/ Ale żadne z nich nie jest obsługiwane przez MSFT.

Silverlight to nie tylko przeglądarka . Od wersji 3 istnieje OOB i byłaby to droga, którą wybrałbym, gdyby platforma obsługiwana przez Microsoft była koniecznością.

Chociaż mono może się opóźniać, nie jest tak usuwane ze stosu .NET, jak możesz myśleć, i nie powinno być odrzucane jako realna opcja.

Dlaczego Microsoft nie implementuje całego stosu .NET; ROI

Większość zysków Microsoft pochodzi z dwóch produktów - Windows i Office. Kompatybilność między platformami zaszkodziłaby Windowsowi.

Jeśli naprawdę chcesz, aby ten sam kod działał na wielu platformach, napisz aplikację internetową. Ale to nie brzmi tak jak ty. „Na wszelki wypadek” nie jest dobrym powodem, jest to pełzanie po zakresie.

Nawet jeśli zdecydujesz się na atak na Mac OS X lub iOS za 16 miesięcy, czy naprawdę uważasz, że możesz wziąć istniejący kod C ++ i przekształcić go w dobrą (lub nawet funkcjonalną) natywną aplikację? Jeśli nie pracujesz nad grą pełnoekranową, odpowiedź brzmi „nie”.

Zaoszczędź czas dzięki C #, a jeśli zdecydujesz się przenieść na Maca, przepisz go na Macu z Objective-C i Cocoa - użytkownicy ci podziękują.

czy jest jakaś autorytatywna odpowiedź na pytanie, dlaczego Microsoft po prostu nie obsługuje platformy .NET na samym komputerze Mac?

Gdzie jest rynek, który uzasadniałby, że MS wydaje skarb, który go koduje? Aby to zrobić, musieliby upuścić poważną gotówkę - miliony dolarów pensji. Ciągły proces wraz z nadejściem poprawek i aktualizacji.

I po co? Chwalenie się prawami? Wydobywają się z tego, że ludzie mogą porzucić Windows dla Apple'a i nadal móc uruchamiać swoje aplikacje.

Jeśli ktoś skorzystałby na tym, byłby to Apple. Ułatw ludziom przejście na platformę, a programistom (DEVELOPERS DEVELOPERS) na nią kodować. Ale czy uważasz, że SJ to bzdura? Wolą wymyślać nowe rzeczy, aby trzymać się í Infront. Poza tym większość frameworka to system operacyjny, a specyfikacje CLR są bezpłatne dla każdego do wdrożenia. Na żadnym z nich nie można nakleić brudnej NDA.

Projekt MonoMac może się przydać - http://www.mono-project.com/MonoMac

Umożliwia tworzenie aplikacji Cocoa w stylu mono, które można wdrożyć w sklepie Mac App Store.

Zdecydowanie uważałbym to podejście za programistę nieznającego Objective-C, ale z .NET / Mono / Java, który musi dostarczyć aplikację w scenariuszu ograniczonym czasowo.

Żaden.

Polecam albo napisanie aplikacji C ++ umożliwiającej kompilację krzyżową - możesz mieć z tego radość - albo użycie Ruby z wxWidgets.

Uważam .NET za złą propozycję dla rozwoju międzyplatformowego i długoterminowej konserwacji produktu. Chociaż, stary, możesz szybko wypróbować w nim aplikacje. : - /

Wish Delphi nadal był głównym konkurentem.

Jeśli chcesz uruchomić .NET natywnie na komputerze Mac, możesz to zrobić za pomocą BootCamp (tzn. Uruchamiasz system Windows na komputerze Mac, a aplikacje .NET w systemie Windows).

Jeśli miałeś na myśli Mac OS X, a nie tylko sprzęt, możesz użyć VMWare lub Parallels do uruchamiania aplikacji .NET w systemie Windows (w emulacji) w OS X. Oba mają tryby wizualne, dzięki którym Twoja aplikacja wygląda tak, jakby działała tylko w systemie OS X (będzie wyglądał i zachowywał się jak aplikacja Windows, ale jeśli piszesz wieloplatformową aplikację inną niż internetowa bez niestandardowego interfejsu dla każdego systemu operacyjnego, zawsze będziesz miał ten problem).

W ten sposób uzyskasz taką samą „obsługę”, ponieważ uruchamiasz aplikację w systemie Windows, choć jest ona zwirtualizowana. Oczywiście, każdy, kto uruchomi aplikację, będzie potrzebował kopii oprogramowania do wirtualizacji i systemu Windows, i będzie gotów zaakceptować aplikację, która nie zachowuje się jak aplikacja OS X - ale jest to jedyny sposób, aby mieć „natywną” .NET działa na komputerze Mac.

Dan, nie sądzę, że możesz to zrobić. Jednak możliwym rozwiązaniem (nadal vapourware) jest użycie Embarcadero Rad Studio C ++ Builder, który ma przyjemne VCL do tworzenia aplikacji wizualnych (na których oparta jest duża część .net), i są RUMOROWANE, aby uzyskać wsparcie między platformami w następnej wersji.

Zostanie to opracowane w systemie Windows, przeznaczone dla komputerów Mac lub Linux. A przynajmniej tak mówi ich mapa drogowa.

Środowisko C ++ jest rozsądne i jeśli programujesz w oparciu o VCL, teoretycznie aplikacja będzie działała na innych platformach.

Oczywiście, dopóki nie zostanie faktycznie wysłany, okaże się, jak skuteczne jest to naprawdę.

Odpowiedź brzmi nie.

W rzeczywistości twoja sprawa wydaje się być bardzo dobrym przykładem tego, kiedy nie wybierać .NET.

Jeśli chcesz opracować system operacyjny, użyj odpowiednich narzędzi. Nie ma naprawdę profesjonalnych aplikacji napisanych mono na komputery Mac. Z drugiej strony jest wielu nieprofesjonalnych programistów używających wielu narzędzi tworzących dużo śmieci. Spójrz na recenzje aplikacji mono napisane dla OSX. Deweloperzy piszą przy użyciu niekompletnej struktury zhakowanej w celu dopasowania do platformy OSX. Zacznij pisać - jeśli używałeś C # Cel C to szybkie nauczenie się.

Profesjonalni programiści dla komputerów Mac używają C ++, Objective C, Cocoa i Xcode. Tworzę na kilku platformach, a każda z nich ma swoje najlepsze narzędzia. Użyj Xcode na Maca i iOS.

Podobnie jak uwaga dodatkowa, Xcode nie jest Visual Studio, nie jest tak stabilny i jest hańbą dla jabłka w porównaniu, ale działa dobrze, gdy przyzwyczaisz się do dziwactwa. Bardzo trudno jest pokonać narzędzia Microsofts - ale zostały napisane dla systemu Windows, a nie Linux, iOS, OSX, AIX itp.