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

11

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.

c# .net mac mono .Аn
źródło
2
Obsługiwany przez kogo?
Dlaczego tak naprawdę obchodzi cię, czy stwardnienie rozsiane to obsługuje? IMO powinno mieć większe znaczenie, jeśli Apple obsługuje tę funkcję, jeśli chcesz kierować reklamy na komputery Mac.
alternatywny
Korzystanie z C ++ nie jest złym pomysłem. Możesz mieć przenośną bazę kodu i używać natywnego GUI na każdej platformie.
mike30
1
Aby zaktualizować ten post, wygląda na to, że MS zwróciło uwagę i zaczną obsługiwać .NET na różnych systemach operacyjnych, choć nie jest jasne, jak to zrobić. Możesz tworzyć aplikacje wieloplatformowe z .NET za pomocą NOV: nevron.com/products-open-vision.aspx (pracuję dla tej firmy). Ogólnie pozwala na kodowanie w C # w systemie Windows, a następnie kompilację dla Wpf, MAC, Silverlight, a wkrótce dla iOS i Androida. Istnieje darmowa (społeczna) edycja tego produktu, więc nie trzeba poświęcać wydajności i trzymać się tajemnego C ++.
Bob Milanov

Odpowiedzi:

17

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
jpobst
źródło
5
You spend hundreds of millions of dollars and several years porting .NET to the Mac.Przepraszam? Ta liczba brzmi trochę wysoko ... Jestem pewien, że Mono-Framework (z obsługą wielu innych systemów operacyjnych) nie kosztował tyle.
Bobby
1
@Bobby: tak myślę. Mono + Silverlight wydaje się tam w większości przypadków. Dodaj do tego trochę P / Invoke i / lub C ++ / CLI dla mniej popularnych rzeczy (Kryptografia, AD itp.) I myślę, że masz całkiem rozsądne rozwiązanie za rozsądną cenę. Moim argumentem jest to, że Microsoft NIE chce wydawać pieniędzy, pomagając ludziom wejść na OSX; jeśli nie, ludzie przestaną używać C # / .NET w systemie Windows.
Ðаn
@ Dan: Dokładnie, Microsoft nie chce być kompatybilny ze światem, inaczej świat mógłby użyć czegoś innego. ;)
Bobby
15
Framework Mono nie jest także kompletnym, w pełni przetestowanym, udokumentowanym, obsługiwanym rozwiązaniem. Istnieje różnica w tym, co jest „wystarczająco dobre” dla oprogramowania typu open source i jakości, jakiej ludzie oczekują od Microsoftu. Wykonanie ich na poziomie wymaganym przez użytkowników z łatwością kosztowałoby setki milionów dolarów. Aby zmniejszyć inwestycję, mogliby wybrać popularny (i przenośny) podzbiór platformy .NET i po prostu to zrobić. To właśnie postanowili zrobić, nazywają to „Silverlight”.
jpobst
@jpobst, ale wygląda na to, że stwardnienie rozsiane właśnie to zrobiło ... i więcej?
Ðаn
14

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).

Barry Wark
źródło
Zarządzanie nie wydaje się zbyt skłonne do korzystania z opcji Mono. I z pewnością nie obsługiwał platformy .NET 4.0 w tym samym dniu co w systemie Windows (lub?).
15аn
Czy Silverlight nie jest już w większości na froncie WPF (podobnym)? Tak, XAML musiałby być inny, aby uzyskać wygląd komputera Mac.
15аn
2
@Dan: Sposób, w jaki Mono przenosi się w dzisiejszych czasach, jeśli zaczniesz opracowywać aplikację dla najnowszej wersji .NET, kiedy Microsoft ją wyda, Mono będzie obsługiwać tę samą wersję, zanim aplikacja będzie gotowa do wysyłki.
Anon.
@Dan SL i WPF pod przykryciem próbują połączyć się w jak największym stopniu. Istnieją różnice techniczne, ale podstawowe koncepcje są wieloplatformowe.
Aaron McIver
6
Jeśli zarząd Twojej firmy nie chce używać Mono, nie będziesz w stanie uczynić aplikacji komputerowej napisanej w tradycyjnym C # 4.0 tak prostym.
Ramhound
5

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.

Ishpeck
źródło
4

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

Aaron McIver
źródło
Ale wygląda na to, że są tak blisko z Silverlight ... dlaczego nie skończyć pracy? Wydawałoby się to o wiele lepsze dla wszystkich niż kompilator, CLR itp. W inżynierii wstecznej Mono
od
1
SL to nie cały stos .NET. Środowisko wykonawcze SL w porównaniu do całego stosu .NET to zupełnie inne zwierzęta.
Aaron McIver,
Tak, ale skoro możesz już robić takie rzeczy jak OOB, jak sugerujesz w SL, dlaczego nie przenieść pozostałej części (1/3? 40%?) Stosu .NET? A może SL to tak naprawdę próba zabicia Flasha?
11:30
@ Dan Kiedy firmy wypychają rzeczy do chmury ... ostatnią rzeczą, którą chcesz zrobić, to przenieść stos, który nie może działać w chmurze. SL może działać w różnych przeglądarkach. Możesz kłócić się z takimi firmami jak Google i inni, że nacisk na pracę w przeglądarce jest prawdziwy. Dlaczego w tej chwili miałbyś zdecydować się na przeniesienie całego stosu do systemu operacyjnego z <10% udziałem w rynku wraz z wirtualizacją tak powszechną w dzisiejszych czasach?
Aaron McIver,
Microsoft (prawdopodobnie) ma najlepsze dostępne obecnie środowisko programistyczne z C # i .NET. Ale firmy takie jak moja będą coraz bardziej się tego unikać z powodu niepewności otaczającej komputery Mac / iPad / cloud / itp. C ++ wydaje się znacznie bezpieczniejszy.
15аn
3

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ą.

Tobias Cohen
źródło
1
„Na wszelki wypadek” jest rzeczywistością; nikt nie chce powiedzieć zarządowi „ups”, kiedy w C ++ jest bezpieczniejsza opcja.
15аn
1
Zakładając, że kod interfejsu jest poprawnie oddzielony, łatwiej będzie przenieść kod C ++ na komputer Mac. Przepisz interfejs w Objective-C używając Cocoa, połącz z resztą, a ty wykonałeś całą robotę.
David Thornley,
@David: i stąd problem związany z tym pytaniem: więcej C ++, (dużo) mniej C #. Naprawdę lubię C #!
15аn
Te obawy międzyplatformowe tutaj są powodem, dla którego wielu z nas nadal używa Java i nie przechodzi do C #.
Brian Knoblauch,
1

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.

Oszukany
źródło
Częścią „tego, co jest w Microsoft”, jest utrzymywanie ludzi przy użyciu najlepszych narzędzi w systemie Windows. Sposób, w jaki wszystko się tutaj dzieje, C # /. NET zostanie przeniesiony do aplikacji wewnętrznych. Programiści, którzy używają C # od lat, ponownie piszą w C ++. Co do kosztów; wygląda na to, że są już w 2/3 z Silverlight i / lub Mono.
15аn
Mono jest platformą typu open source i chociaż zostało wydane źródło .NET, platforma .NET Framework NIE jest open source. Microsoft nie będzie w stanie kupić Mono, z wielu powodów, najważniejszym z nich jest to, że nie mają jednej aplikacji w 100% open source. Czy wiesz, że Silverlight to tylko jeden język w .NET i powód, dla którego jest on wieloplatformowy, ponieważ Microsoft chciałby, aby był zamiennikiem Flasha. Powinienem również dodać, że Apple wykonał ruchy ręką, aby nawet nie pozwolić na coś takiego w swoim systemie operacyjnym.
Ramhound
1
@Dan wydaje się, że rozwiązaniem twoich nieszczęść nie jest „jeden język, który rządzi nimi wszystkimi”, ale „Jak wdrażamy w sposób niezależny od platformy”. Większość ludzi osiąga to poprzez zerwanie interfejsu użytkownika z logiką, osadzając jedną na platformie, a drugą jako usługę na serwerach internetowych.
Zerwano
1
@ Dan Mam na to rozwiązanie ... Nie koduj na Maca. Mam osobistą umowę Non Develop-for-Apple, którą sam napisałem i podpisałem. Zupełnie nie chciałbym kodować C #, więc unikam tego. Ale czasami musisz zrobić to, co musisz, a jeśli życzenia byłyby rybami, musielibyśmy wymyślić inne aliteracje, aby opisać wiele rzeczy, których chcemy, ale których nie możemy mieć.
Zgrane
1
@Dan kindasorta. Tak naprawdę nie dotknęły pulpitu (jeszcze). Ale jestem zdumiony różnicą, jaką robi pięć lat.
Zerwano
0

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.


źródło
0

Ż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.

Paul Nathan
źródło
1
Słyszałeś kiedyś o Łazarzu?
Happy Coder,
Czy kiedykolwiek byłeś szefem Javy?
Fernando Gonzalez Sanchez,
0

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.

Tony Meyer
źródło
0

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ę.

szybko
źródło
-2

Odpowiedź brzmi nie.

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

Gabriel Magana
źródło
Nikt nie może przewidzieć przyszłości i nikt nie chce podjąć „nadmiernego” ryzyka.
15аn
@Dan: I chodzi o to? Wygląda na to, że się ze mną zgadzasz ...?
Gabriel Magana
-3

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.

Dr. Maynord
źródło
1
Czy masz jakieś fakty do tworzenia kopii zapasowych oświadczeń, takich jak „Xcode nie jest tak stabilny i jest hańbą dla Apple”, ponieważ na podstawie mojego własnego doświadczenia wszyscy, którzy używali Xcode, pokochali to. Poza tym nawet po wyrażeniu osobistej opinii na temat, z którym wydaje się, że nie znasz go, nawet nie zdajesz sobie sprawy, że w 2013 roku istnieje rozwiązanie. Oczywiście rozwiązanie jest rzeczywiście Mono, a Xamarin.Macjednak jest to rozwiązanie. Obecna wersja Mono jest prawie w 100% pełną implementacją .NET 4.0, brakuje jej tylko kilku głównych funkcji, które prawdopodobnie nigdy nie zostaną przeniesione (np. WPF).
Ramhound