Если писать под .NET 2.0 то на сайте написано надо ставить Mono 1.9, не меньше, причём в Mono 2.2 они пофиксили кучу ошибок в System.Windows.Forms, так что делай выводы. В MacOSX обещают исправить глюки к версии Mono 2.6, то есть ещё пол года ждать.


Будут глюки с реализациями Моно разных версий и для разных ОС. Правильно они там на их сайте говорили, надо подставлять собственные реализации Моно имитирующие .NET Framework, во время отладки естественно.


Популярные опенсорс проекты во всяком случае, они все имеют реализации под вторую версию. Наверное это связано с тем, что вместо того, чтобы дописать фреймворки, майкрософт делает новые несовместимые форматы. Так и жду в ближайшем будущем .NET Framework 15.1. Главное в начале они хвастались, что сделали лаконичный язык C#, а теперь уже такого наворотили.

Тебя обманули :(


Угу. У нас 3.5. Библиотеки - конечно, должны ориентироваться на 2.0 (ну, если это не библиотека контролов для WPF или какой-нить провайдер для LINQ-а). А проекты - зависит от направлению. Небольшие приложения - конечно, должны ориентироваться на 2.0, а полномасштабные системы - не вижу причин не использовать свежий фреймворк.


Тоже интересно 


Тебя тоже обманули  Какие ещё несовместимые форматы?! CLR во внешнем плане со 2-ой версии фреймворка не менялась.



Это сообщение отредактировал(а) Любитель - 19.2.2009, 12:58

Причём здесь CLR фреймворка , тема топика C# под линукс, конкретно под ubuntu и следовательно через Mono. И тебя вылечим, и тебя вылечим, может даже и меня вылечим.  

Ещё раз какие ещё "несовместимые форматы"? Между чем и чем? И форматы чего?

PS. Подправил случайную ошибку в предыдущем посте - речь про 3.5 фреймворк, а не 3.0

Это сообщение отредактировал(а) Любитель - 19.2.2009, 12:59

Он там есть, просто модель компоновки для тебя непривычна, т.к. основана на контейнерах, а не на пикселях.

А полномасштабные весьма длительны по времени, и тоже никто не видит причин переводить разработку начатую в 2007-2008 годах на .NET 2.0 на более свежие версии .NET


большинство из тех проектов, про которые я точно знаю на какой версии их пишут. 
большая часть статистики собрана по Epam Systems, и это не смотря на то, что Epam - один из основных золотых партнеров MS, подумай об этом... 


где это он так позиционируется?   

Всё, что не входит в ECMA - в общем случае идёт лесом. Что именно туда идёт поможет узнать MoMA, так что написать кроссплатформенное приложение на .NET не составит труда при желании.  


Это из серии, что лучше "программировать на языке" или "с использованием языка". Т.е. всё зависит от того, с какой стороны смотреть...
У тебя "ассоциируется с Qt" и ладно, я не против   


Это ты про что? Что тебе мешает указать минимальную версию Mono, необходимую твоему приложению? 

Просто программисты любят обходиться стандартными средствами, в случае с java это не очень приятный внешне swing. В любом случае, было бы желание, то стоило бы использовать замечательную QtJambi или SWT на крайний случай.

У меня очень небольшой опыт программирования на C#, но после WinForms, упоминаемый выше GTK# с полноценным layout manager-ом, показался более удачным для личных нужд. Если когда-нибудь взбредет в голову написать что-нибудь just for fun под платформу Mono, то для разработки думаю буду глядеть на связку nant + текстовый редактор (например kate). Ибо MonoDevelop светлых чувств не вызывает.

source777, 



У меня такое чувство, что вы всё смешиваете в кучу - Язык C# вместе с его синтаксисом и т.д. и .NET как библиотеку классов
Запросто можно написать приложение, которое полностью будет соответствовать ECMA, но всё равно не сконвертится под Mono...







Сколько из этих "полномасштабных" реально кросс-платформенны?

Что ты, просто ECMA стандарт есть не только на C#, но и на CLI! Кстати .NET - это не библиотека классов ;-)

  очень интересно посмотреть на такое, особенно с учётом, что самая свежая версия стандарта датируется июнем 2006 года.

Нисколько, не было подобной цели  Может это покажется странным, но кроссплатформенность одна из самых невостребованных возможностей в Enterprice-секторе.

Нисколько не покажется странным. Если говорить про энтерпрайз, то (для .Net-а) это ещё  и обычно IIS, MS SQL Server (в том числе Reporting/Analysis services), интеграция с ActiveDirectory, MTS и пр. Моно на это не претендует. WCF в моно нет (по крайней мере, когда я глядел, даже в планах не было). Веб-сервисы даже в не супер состоянии. Ну какой тут энтерпрайз?! 

source777,  

1. А я не говорил, что .NET - это одна только библиотека классов ;) Но говорил именно об этой части .NET...
2. Полное соблюдение ECMA не мешает мне случайно использовать то, что в Mono ещё не реализовано...Вы что...предлагаете мне после изменения каждой строки кода и вообще после каждого чиха прогонять сборку через MoMA? ))

Главным образом плохо то, что Mono отстаёт от .NET Framework'ов. Следовательно несовместимость на уровне операционных систем. Ещё им вменяется в вину изменение существующих спецификаций языков, и создание новых ненужных возможностей. Вот на кой им понадобилось вводить лямбда-выражения. Был себе язык как язык, а такими темпами последняя версия C# скоро C++ обгонит по уровню избыточного программирования.


А зачем, напишешь часть функционала, тогда и прогонишь через MoMA.

Это не Ъ

Это типа "не видел, но осуждаю". Почему это "избыточная возможность"?! И причём "форматы"?

раз в неделю достаточно.

да, в крупных Enterprice-приложениях встречается то, что ты перечислил, но дело даже не в этом, просто там в принципе никому не нужна кроссплатформенность, даже если она вполне возможна.
Что касается WCF, то её частичная поддержка есть в Mono (в рамках подпроекта Olive) с самого момента появления WCF, можешь почитать статью Mono Olive: Introducing Windows Communication Foundation от сентября 2007 года... или о текущем статусе тут.

source777,

 вот именно...  Эдакий клон дотнета, но без рук и без ног