Есть ли поддерживаемый способ запуска приложений .NET 4.0 на Mac?

11

Каковы, если таковые имеются, поддерживаемые Microsoft варианты для запуска кода C # /. NET 4.0 изначально на Mac? Да, я знаю про Mono, но помимо всего прочего она отстает от Microsoft. И Silverlight работает только в веб-браузере. Решение типа VMWare тоже не подойдет.

Есть ли какой-нибудь полу-авторитетный ответ на вопрос, почему Microsoft просто не поддерживает .NET на самом Mac? Казалось бы, они могли бы Silverlight и / или купить Mono и быстро быть там. Нет необходимости в родной Visual Studio; кросс-компиляция и удаленная отладка в порядке.

Причина в том, что там, где я работаю, растет неопределенность в отношении будущего, что заставляет гораздо больше разрабатывать C ++ вместо C #; новые проекты выбирают для использования C ++. Никто не хочет говорить руководству через 18–24 месяца «извините», если Mac (или iPad) станет требованием. C ++ рассматривается как более безопасный вариант, даже если это (возможно) означает потерю производительности сегодня.

c# .net mac mono Ðаn
источник
2
При поддержке кого?
Почему вас это волнует, если MS поддерживает это? ИМО должно иметь большее значение, если Apple поддерживает его, если вы хотите настроить Mac.
альтернатива
Переход на C ++ - неплохая идея. Вы можете иметь переносимую кодовую базу и использовать встроенный графический интерфейс на каждой платформе.
mike30
1
Чтобы обновить этот пост, похоже, что MS обратила на это внимание, и они начнут поддерживать .NET на разных ОС, хотя неясно, как это будет сделано. Вы можете создавать кроссплатформенные приложения с помощью .NET, используя NOV: nevron.com/products-open-vision.aspx (я работаю в этой компании). Как правило, он позволяет кодировать на C # в Windows, а затем компилировать для Wpf, MAC, Silverlight и в ближайшее время для iOS и Android. Существует бесплатная (общественная) версия этого продукта, поэтому нет необходимости жертвовать производительностью и придерживаться тайного C ++.
Боб Миланов

Ответы:

17

Есть ли какой-нибудь полу-авторитетный ответ на вопрос, почему Microsoft просто не поддерживает .NET на самом Mac?

Лучший ответ, вероятно, заключается в том, что вы не «просто поддерживаете» .NET на Mac. Вы тратите сотни миллионов долларов и несколько лет портируете .NET на Mac.

Хотя некоторые вещи полностью управляются и не требуют портирования, большинство из них являются оболочками вокруг Win32 API (окна, элементы управления, gdi +, криптография, активный каталог, COM, корпоративные службы, доступ к устройству, звук, видео, кодеки, winforms и т. Д., так далее).

Каждый из них должен быть абстрагирован в бэкэнде и преобразован в эквивалентные нативные библиотеки в OSX. Конечно, не будет хорошего чистого отображения, поэтому вы также должны писать хаки на хаки, чтобы они работали точно так же.

Кроме того, существует проблема, заключающаяся в том, что эти API-интерфейсы в OSX могут быть хрупкими, и Apple не очень хороша в отношении обратной совместимости, поэтому вы получаете возможность повторять свои хаки с каждым основным выпуском (а иногда и второстепенным выпуском и исправлениями), что повышает стоимость обслуживания.

По сути, это огромная сумма денег и работа за очень небольшую выгоду на платформе, владелец которой был бы против того, чтобы вы делали это в любом случае. И вы действительно не хотите тратить деньги, чтобы помочь людям перейти с вашей платформы на платформу конкурента.

Таким образом, вы получаете не идеальный кроссплатформенный выбор:

  • C ++, который все еще потребует портирования в будущем
  • Silverlight вне браузера, для поддержки Microsoft
  • Mono, которая работает для поддержки здорового подмножества .NET, но не Microsoft
jpobst
источник
5
You spend hundreds of millions of dollars and several years porting .NET to the Mac.Извините? Это число звучит немного выше ... Я уверен, что Mono-Framework (с поддержкой многих других ОС) не стоил так дорого.
Бобби
1
@Bobby: вот о чем я думаю. Mono + Silverlight, кажется, в большинстве случаев. Добавьте к этому немного P / Invoke и / или C ++ / CLI для менее распространенных вещей (криптография, AD и т. Д.), И я думаю, что у вас будет довольно разумное решение по разумной цене. Я утверждаю, что Microsoft хочет потратить деньги, помогая людям перейти на OSX; если они этого не сделают, люди перестанут использовать C # / .NET в Windows.
Ðаn
@Dan: Точно, Microsoft не хочет быть совместимой с миром, иначе мир мог бы использовать что-то другое. ;)
Бобби
15
Платформа Mono также не является полным, полностью протестированным, документированным, поддерживаемым решением. Есть разница в том, что является «достаточно хорошим» для открытого исходного кода и качества, которого люди ожидают от Microsoft. Для них было бы легко потратить сотни миллионов долларов, чтобы сделать это в соответствии с требованиями уровня пользователей. Чтобы уменьшить инвестиции, они могли бы выбрать популярное (и переносимое) подмножество .NET Framework и просто сделать это. Это то, что они решили сделать, они называют это «Silverlight».
jpobst
@jpobst, но похоже, что MS сделала именно это ... и больше?
Ðаn
14

Нет, Silverlight - это единственный вариант Microsoft от .Net на OS X. Mono не «отстает» так сильно, как вы думаете; например, он поддерживает .Net 4.0 и C # 4. Однако наборы инструментов пользовательского интерфейса (WinForms и WPF) не очень хорошо поддерживаются в OS X. Mono вообще не поддерживает WPF. Microsoft также не смогла переписать весь движок рендеринга. Это, вероятно, хорошо, хотя. Если вы хотите написать собственное приложение для Mac, вам следует написать собственный пользовательский интерфейс (возможно, с использованием MonoMac).

Барри Уарк
источник
Менеджмент, похоже, не склонен соглашаться с опцией Mono. И, конечно, он не поддерживал .NET 4.0 в тот же день, что и в Windows (или?).
Ðаn
Разве Silverlight уже не в основном на WPF (-подобном) фронте? Да, XAML должен отличаться, чтобы получить внешний вид Mac.
Ðаn
2
@Dan: как Mono движется в наши дни, если вы начнете разрабатывать приложение для последней версии .NET, когда Microsoft выпустит его, Mono будет поддерживать эту же версию к тому времени, когда приложение будет готово к выпуску.
Анон.
@Dan SL и WPF под крышками пытаются объединить как можно больше. Есть технические различия, но фундаментальные концепции являются кроссплатформенными.
Аарон Макивер
6
Если руководство вашей компании не желает использовать Mono, вы не сможете сделать настольное приложение, написанное на традиционном C # 4.0, таким простым.
Ramhound
5

Нет. Моно - твоя лучшая ставка.

Другие проекты с открытым исходным кодом, такие как DotGNU, также могут вам помочь. http://www.gnu.org/software/dotgnu/ Но ни один из них не поддерживается MSFT.

Ishpeck
источник
4

Silverlight не только браузер . Начиная с версии 3 OOB существовал и был бы тем путем, который я выбрал бы, если бы необходима платформа с поддержкой Microsoft.

Хотя Mono может отставать, он не так удален из стека .NET, как вы думаете, и его не следует отбрасывать как жизнеспособный вариант.

Что касается того, почему Microsoft не реализует весь стек .NET; ROI.

Аарон Макивер
источник
Но кажется, что они так близки с Silverlight ... почему бы просто не закончить работу? Это , казалось бы , так лучше для всех , чем Mono реверс-инжиниринг компилятор, CLR и т.д.
Ðаn
1
SL не весь стек .NET. Среда выполнения SL по сравнению со всем стеком .NET - это совершенно разные животные.
Аарон Макивер
Да, но, поскольку вы уже можете делать такие вещи, как OOB, как вы предлагаете с SL, почему бы не перенести остальные (1/3? 40%?) Стека .NET? Или SL действительно не более чем попытка убить Flash?
Ðаn
@Dan Когда компании отправляют вещи в облако ... последнее, что вы хотите сделать, это перенести стек, который не может работать в облаке. SL может работать через браузеры. Вы можете поспорить с подобными Google и другими, что работа в браузере реальна. Почему в этот момент вы решили портировать весь стек на ОС с долей рынка <10% наряду с виртуализацией, столь распространенной в наши дни?
Аарон Макивер
Microsoft (возможно) имеет лучшую на сегодняшний день среду разработки с C # и .NET. Но такие компании, как моя, будут все больше избегать этого из-за неопределенности, связанной с Mac / iPad / облаком / и т. Д. С ++ кажется намного безопаснее.
Ðаn
3

Большая часть прибыли Microsoft поступает от двух продуктов - Windows и Office. Кроссплатформенная совместимость повредит Windows.

Если вы действительно хотите, чтобы один и тот же код выполнялся кроссплатформенно, напишите веб-приложение. Это не похоже на то, как ты. «На всякий случай» - не веская причина, это ползучесть.

Даже если вы решите нацелиться на Mac OS X или iOS через 16 месяцев, вы действительно думаете, что сможете взять свой существующий код C ++ и превратить его в хорошее (или даже функциональное) нативное приложение? Если вы не работаете над полноэкранной игрой, ответ - нет.

Сэкономьте время с C # сейчас, и если вы решите перейти на Mac, перепишите его на Mac с Objective-C и Cocoa - ваши пользователи будут вам благодарны.

Тобиас Коэн
источник
1
«На всякий случай» - это реальность; никто не хочет говорить руководству "упс", когда есть более безопасный вариант в C ++.
Ðаn
1
При условии, что код интерфейса правильно разделен, будет проще перенести код C ++ на Mac. Перепишите интерфейс в Objective-C, используя Какао, ссылку на остальное, и вы сделали большую часть работы.
Дэвид Торнли
@ Дэвид: и, следовательно, проблема, стоящая за этим вопросом: больше C ++, (намного) меньше C #. Мне (очень) нравится C #!
Ðаn
Именно из-за этих кросс-платформенных проблем многие из нас все еще используют Java и не переходят на C #.
Брайан Кноблаух
1

Есть ли какой-нибудь полу-авторитетный ответ на вопрос, почему Microsoft просто не поддерживает .NET на самом Mac?

Где рынок, который оправдал бы трату MS на то, чтобы кодировать его? Чтобы сделать это, им пришлось бы бросить серьезные деньги - миллионы долларов зарплаты. Постоянный процесс, исправления и обновления.

И для чего? Хвастаться правами? Все, что они получают от этого, - это способность людей отказаться от Windows для Apple и иметь возможность запускать свои приложения.

Если кому-то это выгодно, это будет Apple. Облегчить переход людей на свою платформу, а разработчикам (РАЗРАБОТЧИКАМ-РАЗРАБОТЧИКАМ) создавать на ней код. Но вы думаете, что SJ дерьмо? Они лучше придумать новый материал , чтобы вставить в я линии всасывания. Кроме того, большая часть фреймворка - ОС, а спецификации CLR бесплатны для всех. Вы не можете наклеить грязную NDA на любой из них.

Сорвал
источник
Часть того, что нужно Microsoft, заключается в том, чтобы люди использовали свои первоклассные инструменты в Windows. То, как все происходит здесь, C # /. NET будет отнесено к собственным приложениям. Разработчики, которые годами используют C #, снова пишут C ++. Что касается стоимости; Казалось бы, они уже около 2/3 с Silverlight и / или Mono.
Ðаn
Mono - это платформа с открытым исходным кодом, и хотя исходный код для .NET уже выпущен, .NET Framework НЕ является открытым исходным кодом. Microsoft не сможет приобрести Mono по многим причинам, главная из которых заключается в том, что у них нет ни одного 100% -го открытого приложения. Знаете ли вы, что Silverlight - это всего лишь один язык в .NET, и почему он мультиплатформенный, потому что Microsoft хотела бы, чтобы он заменял Flash. Я также должен добавить, что Apple предприняла шаги в сторону, даже не допустив чего-то такого в своей операционной системе.
Ramhound
1
@ Дэн звучит так, как будто решение ваших проблем - не «один язык, чтобы управлять ими всеми», а «Как мы разворачиваемся независимо от платформы». Большинство людей достигают этого, отключая пользовательский интерфейс от логики, встраивая один для каждой платформы в отдельности, а другой в качестве службы на внутренних каналах.
Сорвал
1
@ Дан, у меня есть решение для этого ... Не пишите для Mac. У меня есть личное Соглашение не для Apple, которое я написал и подписал сам. Я бы очень не хотел не иметь возможности кодировать C #, и поэтому избегать этого. Но иногда ты должен делать то, что должен, и если бы желания были рыбами, нам пришлось бы придумать какую-нибудь другую аллитерацию, чтобы описать многие вещи, которые мы хотим, но не можем иметь.
Сорвал
1
@Dan kindasorta. Они еще не коснулись рабочего стола (пока). Но я поражен тем, что изменится за пять лет.
сорвано
0

Возможно, вы найдете проект MonoMac полезным - http://www.mono-project.com/MonoMac

Это позволяет разрабатывать приложения Какао в стиле Mono, которые можно развернуть в магазине приложений Mac.

Я бы настоятельно рекомендовал этот подход для разработчика, незнакомого с Objective-C, но с .NET / Mono / Java, который должен доставлять приложение в условиях ограниченного времени.


источник
0

Никто.

Я рекомендую либо написать кросс-компилируемое приложение на C ++ - может, вам понравится - или использовать Ruby с wxWidgets.

Я считаю .NET плохим предложением для кроссплатформенной разработки и долгосрочного сопровождения продукта. Хотя, чувак, в нем можно быстро выкладывать приложения. : - /

Желаю, чтобы Дельфи все еще был главным соперником.

Пол Натан
источник
1
Вы когда-нибудь слышали о Лазаре?
Счастливый кодер
Кроме того, когда-либо глава Java?
Фернандо Гонсалес Санчес
0

Если вы хотите запускать .NET непосредственно на Mac, вы можете использовать BootCamp для этого (т.е. вы запускаете Windows на Mac и ваши приложения .NET в Windows).

Если вы имели в виду Mac OS X, а не просто аппаратное обеспечение, то вы можете использовать VMWare или Parallels для запуска приложений .NET в Windows (в эмуляции) в OS X. Оба имеют визуальные режимы, которые позволяют вашему приложению выглядеть так, как будто оно только запущено. в OS X (это будет выглядеть и вести себя как приложение Windows, но если вы пишете кроссплатформенное не-веб-приложение без специального интерфейса для каждой ОС, у вас всегда будет эта проблема).

Делая это, вы получите столько же «поддержки», поскольку вы запускаете приложение в Windows, хотя и виртуализировано. Конечно, любому, кто запускает приложение, потребуется копия программного обеспечения для виртуализации и Windows, и он будет готов смириться с приложением, которое не ведет себя как приложение OS X - но это единственный способ получить «родной» .NET работает на Mac.

Тони Мейер
источник
0

Дэн, я не думаю, что ты можешь сделать это. Однако возможное решение (все еще vapourware) заключается в использовании Embarcadero Rad Studio C ++ Builder, который имеет хороший VCL для разработки визуальных приложений (на которых основана большая часть .net), и им НУЖНО иметь кроссплатформенную поддержку, выходящую в следующем выпуске.

Это будет разработано для Windows, предназначено для Mac или Linux. Или так говорится в их дорожной карте.

Среда C ++ разумна, и если вы разрабатываете против VCL, то теоретически приложение будет работать только на других платформах.

Конечно, до его фактической отправки еще неизвестно, насколько это эффективно.

quickly_now
источник
-2

Ответ - нет.

На самом деле ваш случай кажется очень хорошим примером того, когда не стоит выбирать .NET.

Габриэль Магана
источник
Никто не может предсказать будущее, и никто не хочет рисковать.
Ðаn
@ Дэн: И дело в том? Вы, кажется, соглашаетесь со мной ...?
Габриэль Магана
-3

Если вы хотите разрабатывать для ОС, используйте правильные инструменты. Нет действительно профессиональных приложений, написанных в моно для Mac. С другой стороны, многие непрофессиональные разработчики используют множество инструментов, создающих много мусора. Посмотрите на моно обзоры приложений, которые были написаны для OSX. Разработчики пишут, используя неполный фреймворк, взломанный для соответствия платформе OSX. Начните писать - если вы использовали C # Цель C - это быстрое обучение.

Профессиональные разработчики для Mac используют C ++, Objective C, Cocoa и Xcode. Я работаю на нескольких платформах, и у каждой есть свои лучшие инструменты. Используйте Xcode для Mac и iOS.

Как примечание, Xcode не является Visual Studio, он не так стабилен и по сравнению с яблоком позорен, но он хорошо работает, когда вы привыкнете к его причудам. Инструменты Microsoft очень сложно обойти - но они были написаны для Windows, а не для Linux, iOS, OSX, AIX и т. Д.

Доктор майнорд
источник
1
Есть ли у вас какие-либо факты, подтверждающие заявления типа «XCode не так стабилен и позорен для Apple», потому что, основываясь на моем личном опыте, всем, кто использовал XCode, это понравилось. Кроме того, даже после того, как вы выскажете свое личное мнение по теме, с которой вам кажется, что вы не знакомы, вы даже не подозреваете, что в 2013 году действительно существует решение. Конечно , решение на самом деле Monoи , Xamarin.Macно это решение. Текущая версия Mono является почти 100% полной реализацией .NET 4.0, в ней отсутствуют только пара основных функций, которые, вероятно, никогда не будут перенесены (например, WPF).
Ramhound