Microsoft выпустила Shared Source CLI Implementation

Так мля какой толк от него(её) без ASP.NET и WinForms 

пущай де Иказа напишет ^_^

2 anonymous (*) (2002-04-01 12:26:41.0): Еще есть одно ограничение - она для некоммерческого использования. Вам бы, ребята, мед, да еще и ложкой. Когда ж вы руками-то делать хоть что-нибудь научитесь?

ну да shared source - не opensource. но из этих исходников есть чему поучиться. Одно дело -- голые спецификации, другое -- работающий код.

2 yakuza: Кстати "учиться" лицензией явно разрешено. Это не лицензия типа GPL. Cut&paste запрещено, а черпать идеи - сколько угодно.

Мда, а ведь оно таки даже собирается (под XP пробовал) и даже работает. Очень странно, что местные красноглазые как-то весьма индиффирентны к подобным новостям. Щас они будут утверждать что это не про Linux и вообще нахер никому не надь. Btw, под Linux есть как min две рально работающих реализации MS.NET - Mono & Portable.NET (от SilverStone кажется - тоже в сорцах)

Старый пионэр

ну, вообще-то, Mono ни фига не работает под Linux, ПОКА ^_^ Дело в том, что т.к. своего CLR у де Иказы нет, он использует для разработки майкрософтовский. Под cygwin mono собирается за милую душу. На самом деле на настоящий момент mono - это компилятор C# и небольшой кусочек CLI. JIT-компилятор с поддержкой всех фишек .NET Framework -- вещь нетривиальная и было бы глупо ожидать его так скоро. Будем надеяться, что с выходом shared source реализации дело сдвинется с меотвой точки (если кто-то на это хочет надеятся, разумеется ^_^ )

про Linux это, про Linux. Очень надеюсь, что под Linux (да и под другие платформы) будет свой CLR. Иначе какой у него смысл, он ведь дизайнился с portability in mind.

Дык оно понятно. Для ASP.NET нужен IIS, для ADO.NET - СОМ+. Ни того ни другого под FreeBSD нет. А винформы - о каких винформах может идти речь, когда нет конкретного ГУИ?

С другой стороны - нафиг оно все нужно для "некоммерческого" использования. Для учебы хватит с головой и того что дали.

Кстати на go-mono вроде как дела нормально идут, так что скоро .....

Олексий-сан, идите матчасть учить. ASP.NET имеет такое же отношение к IIS, как JSP к Tomcat'у. Да, единственная на данный момент реализация ASP.NET написана как ISAPI-расширение, работающее под IIS, по идее должно работать везде, где поддерживается ISAPI. У ASP.NET завязка с IIS минимальна, разве что на уровне предоставляемого набора серверных переменных (свойство ServerVaribles объекта HttpServerUtility) или еще какой-то мелочи. Основная функциональность -- динамическое формирование классов на онове aspx файла и его компиляция, поддержка серверных контролов и вебсервисов -- от веб-сервера не зависит. ADO.NET с COM+ не связано вообще. Это ADO был набором COM-объектов, в ADO.NET вся библиотека -- чистый managed code. Далее, WindowsForms достаточно абстрактный интерфейс, чтобы переносить его на не-Windows, для этого конечно, понадобится какая-то поддержка со стороны CLR, ну так не привыкать, по другому это не делается (вспомним java и swing...). Наконец, можно было бы разработать биндинги под существующие популярные GUI toolkits, хоть тот же Gtk или Qt или Motif в качестве показательного примера. Однако, кроме де Иказы и иже с ним этим всем никто заниматься не будет, максимум, что может тут сделать Microsoft -- это выпустить shared source реализацию APS.NET, ADO.NET, WindwosForms etc., входит ли это в их планы -- покажет время.

А разве ISAPI одно для всех? Тут я просто не в курсе. Вы хотите стало быть сказать, что плагин от апаче запросто ставится в IIS и наоборот? С трудом верится. В любом случае, какая бы ни была - а завязка есть. А судя по тому что я увидел в этих текстах, МС всячески старалась избежать там какой бы то ни было завязки (особенно на чужие продукты). Тут опять же нельзя путать МС и Sun. В отличие от Сан, МС продвигает свою операционку и свои сервера, поэтому ни о какой привязке к "чужим" продуктам не может быть и речи. Это относится в особенности к ГУИ. Учитывая что код публикуется исключительно для "учебных" целей - естественно что никто не станет просто так публиковать полные исходники готового коммерческого продукта, да еще и адаптированные для безболезненного переноса на конкурирующие системы (хотя линуксоидам хотелось бы именно так). А того что дано вполне достаточно, чтобы самостоятельно (и в меру возможностей и способностей) разработать "правильную" реализацию CLI.

Скомпилил под фрей.
Получил несколько исполняемых файлов nmake и др.
Насколько я понял, nmake хавает build.dat файлы, но при указывании любыхт параметров nmake он матерится "invalid option m". Что делать??