AISOFT:
А вы кстати пробовали писать морду к БД для крупного проекта, с навороченным интерфейсом на .NET ? Чет я сомневаюсь, что можно однозначно сказать, что на .NET построение клиентских приложений лучше, чем в Java или Delphi.

Согласен что интерфейс должен быть простым и удобным. Но еще он должен быть не глюкавым, простым и удобным в работе для программиста. В Delphi и с Java с этим порядок. У .NET визуал для построения виндовых клиентов явно хромает. Вывод сделан из 2 вещей:

1. Видел собственными глазами, как опытный программист, кстати уже написавший и на ASP.NET не один проект, пытался забабацать морду-клиента под небольшую БД, и что из этого получилось. В проекте использовались стандартные компоненты CLR, Crystal Deccision (это тоже отдельный разговор) и скоммунизденный коммерческий грид от C1 (кстати грид в стандартной поставке .NET - это его обрезанная версия), и казалось бы - коммерческий грид, но и тот ловил неплохих глюков и очень "быстро работал".

2. Так как я давно занимаюсь разработкой сложных компонент, в том числе и визуальных, то в первую очередь обращаю внимание больше не на семантику языка, а на библиотеки, без которых этот язык согласитесь абсолютно бесполезен, их продуманность в иеархии классов, открытость, легкость и расширяемость. Так вот анализируя в .NET базовые классы работы с графикой, визуальные компоненты и модель работы с данными я сделал не утешительный вывод - свалка всех решений, подсмотренных Microsoft у других производителей. Причем наваяно в лоб, по принципу - я его слепила, из того, что знала. Уровень графики и визуальных компонент с трудом дотягивает до AWT с Java 1 (помнится мне, что в Visual Java именно и был AWT, понятно откуда ноги растут). Про Swing с Java 2 просто можно не упоминать, в .NET аналогов его просто нет. Разработка компонент - это просто чистый воды геммор. Странно что маздайщики не сделали как в Java поддержки для IDE низкоуровнего зеркального отражения, и на всякий пшик надо писать дизайнеры и тип-конверторы. Ко всему прочему архитектура компонент усложнена тем, что среда их использования многоязыковая, визуальный дизайнер студии свойства компонент сохраняет путем кодогенерации, и из за этого тоже возникают вполне очевидные проблемы и не сильно элегантные пути их обхода, предложенные Microsoft. Очень меня сильно удивило, что визуальные контролы в .NET, ладно - пусть являясь на самом деле API обертками windows-контролов, не инкапсулируют их свойства и возможности полностью (основная проблема VCL). Итог как и следует ожидать в таких случаях всегда один - шаг в сторону, и снова мир WINAPI. Вы заметьте кстати, какие компоненты предлагает Вам создать визард в студии ? Правильно - составные. А в VB6 какие компоненты можно было создавать ? Тут есть определенная аналогия, не смотря на то, что C# и VB.NET чистые ООП языки, CLR сделана так, что там действительно легко только делать составные компоненты, а это уже вызывает аналогию не с обьектно-ориентированными принципами.

Можно конечно еще и проехаться и по модели работы с данными, но думаю смысл понятен - CLR это закрытая от расширения сторонними разработчиками, сделанная в лоб, жестко привязанная к WINAPI, с четко выраженной древовидной структурой иеархия классов, работая на которой вы всегда будете получать глюки от самой Microsoft, а значит и гарантированно от сторонних разработчиков компонент, хорошо знать WINAPI (куда уж без нее то), покупать дорогие коммерческие компоненты только из за того, что в отличие от стандартных они худо бедно, но все таки работают и каждый раз радоваться жизни, думая о том, как все быстро, замечательно и безглюкаво работает в форме About вашего проекта с кнопкой OK. При таком положении вещей на сегодняшний момент конечно же никакой речи о многоплатформенности .NET идти не может (во всяком случае для той ее части, где используется визуал).

Подведение итогов:
Если Microsoft не переделает иеархию CLR и вы научитесь обходить, не замечать, или пользоваться сторонними решениями (не в первой ведь наверное, правда ?), то что то писать можно.
Если же они решат переделать свой windows-костыль на что то нормальное, то где гарантия того, что проект, писанный сейчас вами, будет работать на их новой CLR ? Я думаю пример судьбы проектов, писанных на VB6 и "как" они переносятся на VB.NET наглядное тому свидетельство.

P.S. И тут Остапа понесло (C) Ильф и Петров