FAQ: Что такое VS.Net.
Делаем ставки на то, когда зададут вопрос, ответ на который есть в этом тексте.
Не я думаю, сейчас прибегут приверженцы open-source и начнуть кричать что Linux и FreeBSD the Best вкупе с С++, PHP и MySQL 
Нет-нет.
Будьте добры .NET под Linux.
Будьте добры .NET под Linux.
маза этот тред пришпилить 
mono тебе в руки (хотя это такое дерьмо )
)Оставить комментарий
Dasar
Часто приходится слышать вопросы:Что такое VS.Net?
Как новая студия соотносится с VS6?
Можно и стоит ли старые проекты переносить под новую студию?
Попытаюсь на эти вопросы ответить на основании годичного опыта использования новой студии.
Седьмая версия Visual Studio-и включает в себя три (не считая VB и экзотики) "компилятора": C#, MC++ и VC++. Под "компилятором" я здесь понимаю не только сам компилятор, но и библиотеки, рантайм, поддержу в студии и т.д.
Эти три "компилятора" по большому счету, никак не связаны между собой (особенно C# и VC++ и используются для решения разных задач.
Начнем с конца:
VC++ "компилятор" - это немного улучшенная версия старого доброго VC6. Из основных улучшений: более лучшая поддержка стандарта языка C++ и чуть лучшая оптимизация кода.
Стандартная библиотека MFC (MFC7) почти не изменилась,
ATL (ATL7) изменился сильно, но в основном в сторону добавления новых классов для создания Web-каких-то примочек. Из серьезных изменений - это добавление ATL::CString.
Под новый ATL был выпущен чуть прилизанных WTL7, без каких-либо кардинальных изменений.
Перенос на новый "компилятор" старых проектов, созданных на VC6, проходит без каких-либо серьезных трудностей. Мы управились за два дня.
Основные проблемы были в тех местах, где использовались нестандартные языковые конструкции (например, for (int i = 0; {} for (i = 0;){}) и недокументированные фичи MFC.
В проектах ATL/WTL пришлось разобратся с CString-ом, так как в ATL-е появился свой родной CString, который и хотелось нам использовать.
При переносе ATL-ных проектов столкнулись с тем, что немного поменялся механизм агрегации, из внутренних объектов во время FinalConstruct-а "отвалился" доступ к внешнему объету.
Под эти проекты пришлось патчить новый ATL, чтобы он себя вел как старый.
В целом, переходом на новую версию мы довольны, т.к. новый "компилятор"/студия более фичный, менее бажный и генерирует более лучший код, а сам переход обошелся очень малой кровью.
Теперь с другого края:
C# "компилятор" - это основной язык (опять же, не считая VB.Net) для написания программ под .Net-фреймворк. На данный момент C#/.Net позиционируется, как основная рабочая лошадка, для написания серьезных приложений, раньше такой рабочей лошадкой был C++/MFC.
По своей сути, C#/.Net - это компилируемая "java" с рядом вкусностей (метаданные, очень простая стыковка с унаследованным кодом и т.д. что переводит язык из "области фантастики" в рабочий язык.
Новые проекты очень легко и быстро пишутся на новом языке. C++ программисты легко осваивают новый язык, основное внимание надо обращать на то, чтобы у программистов было хотя бы поверхностное знание того, что уже есть в стандартной библиотеке, иначе неизбежно изобретение велосипедов. Также надо быть внимательным при использовании ряда трюков, привычек, выработанных при написании на C++, на C# эти трюки, привычки могут уже работать не так или делать не то (не достигать тех же целей).
Из основных минусов на данный момент, это то, что программы должны таскать с собой 20мб .net-framework.
Первый свой проект на C# мы написали за 3 месяца. Из них где-то пол-месяца ушло на шатания и брожения (на чем будем писать, будем или не будем использовать новые технологии, в каком объеме и т.д. месяц где-то ушел на освоение новых технологий (активное посещение форума, чтение MSDN-а и книг по .Net) и оставшиеся полтора месяца ушло на непосредственное программирование.
При использовании C++ вместо C#, у нас ушло бы тоже порядка 3 месяцев, причем программа была бы сделана с меньшими фичами и меньшим заделом на будущее.
Теперь середка:
Managed C++ "компилятор" - используется для написания кода на C++ для .Net-framework-а.
В чистом виде почти не применяется, а используется как вспомогательный инструмент в следующих случаях:
1. Это когда мы спускаемся с C# "вниз": хотим использовать низкоуровневую оптимизацию, стыковку с legacy-кодом и т.д., т.е. для тех вещей, которые на C# у нас не получаются или получаются плохо.
2. Либо когда мы, наоборот, берет старый код и пытаемся в нем использовать всю прелесть .Net-framework-а. В этом случае берется старый код и компилируется с использованием managed extensions for C++ (опция /clr далее потихоньку старый код переписывается с использованием новых фич.
Первый подход у нас часто применяется, так как есть много legacy-кода, который хочется быстро подцепить из C#-а.
Второй подход, пока не юзался, только один раз, в тестовых целях, перекомпилировали один из com-серверов на MC++ - никаких проблем не возникло, сервер даже запустился и работал. Но серьезно пока это дело не исследовалось.