Т.к. последнее время я неоднократно встречал вопросы «Что же такое .NET» то, IMHO, единственным правильным решением было написание заметки о том, что же это такое - .NET.
В данной статье я не буду использовать всевозможные рекламные словечки типа "распределенные", "Internet",
"высокопродуктивная", "безопасная" и прочая. Это оставим на совести продавцов. Постараюсь коснуться именно главного – из чего состоит и как работает.
Дальнейшие статьи (а я надеюсь, что я буду делать это более регулярно, чем раньше) буду посвящать различным аспектам программирования под .NET. Само собой все ваши замечания будут приняты с благодарностью и учтены в дальнейшей работе.

Итак, начнем.

Из чего состоит .NET Framework.
.NET Framework состоит из двух основных частей:
1. Среда исполнения
2. Библиотека классов

Среда исполнения
Наверно самое простое объяснение будет выглядеть так – это программа, которая выполняет команды Вашей программы. По сути это интерпретатор. Когда с помощью компилятора какого-либо языка для .NET вы собираете (компилируете) Вашу программу Вы получаете не реальные команды процессора, а некие абстрактные команды, байт-код, промежуточный ассемблер – как Вам удобнее понимать. Т.е. кто помнит QBasic, тот должен помнить, что там команды исполнялись по строчкам. Строка сразу интерпретировалась и исполнялась. В .NET это несколько оптимизировано – среда исполнения работает не с текстом программы, а с уже оптимизированным байт-кодом на языке MSIL - Microsoft Intermediate Language.
На само деле все несколько сложнее – Ваше приложение загружает библиотеку mscorlib.dll и передает управление ей. И уже эта библиотека (которая работает само собой не на MSIL, а на реальных командах процессора)выполняет Ваш код. Кроме этой библиотеки в каталоге с установленной средой исполнения находится еще немало библиотек, но о них речь сегодня мы вести не будем. После загрузки Вашего приложения в память начинается его исполнение. Но и здесь продолжается оптимизация его работы – используется JIT компилятор (Just In Time). Этот компилятор занимается тем, что при первой загрузке кода на MSIL, преобразует его в реальные команды процессора и в дальнейшем Ваше приложение будет использовать уже не MSIL, а полученный код. Такое поведение особенно хорошо видно, когда вы открываете форму с большим количество компонентов, потом закрываете ее и после открываете опять. Первый раз, даже на глаз видно, что система работает гораздо медленнее, чем в последующие.

Как Вы наверно уже поняли, для того, что бы программы написанные под .NET могли быть запущены на другом компьютере, на нем должна быть установлена среда исполнения (устанавливается она в каталог \WINDOWS\Microsoft.NET\Framework\<номер версии>).
Если на компьютере, на котором Вы запускаете свою программу .NET Framework не установлена, то будет выдано, что система не может найти библиотеку mscorlib.dll (о которой я уже упоминал) и само собой дальше этого ничего не пойдет.
По поводу совместимости - на самом деле нормально все это работает начиная с Windows 2000. Хоть и объявлено, что должно работать на Windows 98, Me и Windows NT 4 SP6, но (во всяком случае первая версия .NET) работало это с большим количеством глюков. Так что используйте 2000 или XP.

Что же это нам дает:
1. Возможность повышенной безопасности – Ваша программа не может делать больше того, что ей разрешается. Вы можете с меньшими опасениями использовать незнакомые программы из Internet.
2. Возможность использовать любые языки программирования, которые подпадают под спецификацию - Common Language Specification (CLS) в одном проекте. Почему такое возможно должно быть достаточно очевидно – компилятор любого высокоуровневого языка, удовлетворяющий спецификации, может породить корректный код на MSIL, который в свою очередь без каких-либо проблем будет интерпретироваться средой выполнения.
3. Т.к. код является управляемым, то возникают дополнительные возможности типа метаданных, т.е. данных о самих данных. Вы можете на лету определить тип данных, и даже создать новый тип, скомпилировать и выполнить его.
4. Исчезает «ад dll». Кто уже писал много программ или хотя бы устанавливал много программ, знает, что часто динамические библиотеки могут иметь разные версии, могут быть вообще разными, но иметь одно имя. И все они почему-то хотят стоять в каталоге WINDOWS\System32. Чтобы уметь управлять всем этим хаосом надо немало потрудится. В .NET предполагается, что все, что относится к Вашему приложению должно лежать в одном каталоге и никаких противоречий быть не должно. Мало того, используя механизм метаданных, Вы можете установить точно – какой версии dll будет использоваться Вашим приложением. И никакая другая версия ему не подойдет.
5. Из вышеизложенного должно быть понятно, что система исполнения работает поверх ОС. Таким образом Ваша программа не должна работать с ОС напрямую. Это обеспечивает устойчивость и безопасность системы в целом. Но тем не менее без каких-либо особых затрат Вы можете писать приложения, которые будут работать в операционной системой напрямую. Это может быть обращение к обычным dll или использование так называемого «неуправляемого кода», который будет выполняться как обычный код.

Думаю, что этого объяснения должно быть достаточно для понимания того, что из себя представляет среда исполнения.

Рассмотрим Библиотеку классов
Библиотека классов охватывает просто огромные объемы всевозможных классов и компонент, которые служат для облегчения работы со всевозможными системами и технологиями. Это XML и базы данных, работа с сетевыми ресурсами, технологии SOAP, графическая подсистема. Используя эту библиотеку, Вы можете писать всевозможные виды приложений. Вот список от Microsoft:

- Console applications.
- Windows GUI applications (Windows Forms).
- ASP.NET applications.
- XML Web services.
- Windows services

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

Наверно на этом можно закончить предварительное знакомство с .NET. До скорых встреч.

Никак не могу понять - является ли .NET просто оболочкой над WinAPI?
Мне кажется, что весь этот байт-код в конечном итоге ДЛЯ Windows переводится все в те же вызовы API. Т.е виртуальная машина работает с API..
Или я не прав? Тут все функции переписаны?..

Оболочкой для WinAPI является MFC
При программировании с использованием FCL забудьте об API,MFC,COM,CORBA и так далее
это совет от MICROSOFT

Цитата(AntonSaburov @ 3.2.2004, 17:44)

По поводу совместимости - на самом деле нормально все это работает начиная с Windows 2000. Хоть и объявлено, что должно работать на Windows 98, Me и Windows NT 4 SP6, но (во всяком случае первая версия .NET) работало это с большим количеством глюков. Так что используйте 2000 или XP.

А как на счет Linux'a?

Под Linux?
Тяжко, хотя теоретически реализуемо.
Под Linux есть проект mono.
Но за 3 (по-моему..) года они не смогли обеспечить работу Windows Forms, а вот консольные приложения работают..
Оно и понятно, ведь поддержки толком никакой.
Вот если б M$ позаботился об этом также как Sun о Java..

З.Ы. Сам еще не пробовал..

Слышал что приложения .NET под Линухом бегают очень быстро...
К сожалению сам не опровергнуть не потвердить информацию не могу...

Цитата(Kurt @ 26.2.2004, 20:00)

Никак не могу понять - является ли .NET просто оболочкой над WinAPI? Мне кажется, что весь этот байт-код в конечном итоге ДЛЯ Windows переводится все в те же вызовы API. Т.е виртуальная машина работает с API.. Или я не прав? Тут все функции переписаны?.. ???

На текущей платформе Windows .NET действительно в конечном итоге вызывает WinAPI. А вот когда выйдет Longhorn, все станет наоборот - WinAPI будет эмулироваться средствами .NET. В MS говорят, что WinAPI развиваться дальше не будет, а вся ОС будет работать в managed среде.

Цитата(arilou @ 16.7.2004, 05:37)

На текущей платформе Windows .NET действительно в конечном итоге вызывает WinAPI. А вот когда выйдет Longhorn, все станет наоборот - WinAPI будет эмулироваться средствами .NET. В MS говорят, что WinAPI развиваться дальше не будет, а вся ОС будет работать в managed среде.

а что будеь с ассемблером когда выйдет Longhorn??? как на нем будет писать под .NET не используя эмуляции WinAPI

Deeoni$
Честно говоря, даже не знаю, как-то не задумывался о судьбе ассемблера. Наверное, IL придет ему на замену

Цмтата с одного инф сервера:

Цитата

...Windows Longhorn будет основан на технологии .NET, а приложения Win32(API) будут выполняться в режиме эмуляции...

Но вот вопрос насколко хорошо будет реализована эмуляция???
Кстати, скажите ,плз, что такое IL?

Цитата(ReSeT @ 19.8.2004, 14:46)

Но вот вопрос насколко хорошо будет реализована эмуляция??? Кстати, скажите ,плз, что такое IL?

Насчет качества эмуляции не знаю, но наверное хуже чем Win 95 - Win 3.11 не будет
А нсчет MSIL -

Цитата(AntonSaburov @ 3.2.2004, 17:44)

Среда исполнения Наверно самое простое объяснение будет выглядеть так – это программа, которая выполняет команды Вашей программы. По сути это интерпретатор. Когда с помощью компилятора какого-либо языка для .NET вы собираете (компилируете) Вашу программу Вы получаете не реальные команды процессора, а некие абстрактные команды, байт-код, промежуточный ассемблер – как Вам удобнее понимать. Т.е. кто помнит QBasic, тот должен помнить, что там команды исполнялись по строчкам. Строка сразу интерпретировалась и исполнялась. В .NET это несколько оптимизировано – среда исполнения работает не с текстом программы, а с уже оптимизированным байт-кодом на языке MSIL - Microsoft Intermediate Language.

Цитата

На текущей платформе Windows .NET действительно в конечном итоге вызывает WinAPI. А вот когда выйдет Longhorn, все станет наоборот - WinAPI будет эмулироваться средствами .NET.

Цитата

Честно говоря, даже не знаю, как-то не задумывался о судьбе ассемблера. Наверное, IL придет ему на замену

У меня уже стоИт Longhorn build 4074, эмуляция эта работает ч\з раз, а то и ч\з два - некоторые программы (в частности, использующие RASAPI, IMAP и т.п.) иногда вообще не запускаются, т.е. процесс создается, а форма не рисуется - может программа и работает, но отсутствие GUI делает общение с приложением весьма затруднительным ... а иногда все нормально пашет.
Что касается ассемблера, то fasm программы у меня работают нормально (правда ничего серьезного не запускал, так - свои побрякушки). IL придет на смену API, скорее всего придется нам учить этот новый "Microsoft Intermediate Language" и в include пхать модули с описанием IL констант и функций.
Ну а за судьбу чистого асма (ч\з прерывания, стэк, регистры и т.д. работающего) я спокоен
Если только M$ не прикупит вслед за Borland еще и Intel с AMD
-
Надо срочно искать D8.

Цитата

По сути это интерпретатор

Не совсем согласен. Интерпретатор исполняет текстовые команды, а в .НЕЕЕЕЕЕТ сначала происходит JIT-компиляция. Т.е. при вызове какогонить метода Just-In-Time компилятор сначала компилит IL-код а потом исполняет уже откомпиленный код.

Цитата(Run @ 9.2.2005, 12:20)

Не совсем согласен. Интерпретатор исполняет текстовые команды, а в .НЕЕЕЕЕЕТ сначала происходит JIT-компиляция.

А внимательнее читать не пробовал ?

Цитата(AntonSaburov @ 3.2.2004, 17:44)

После загрузки Вашего приложения в память начинается его исполнение. Но и здесь продолжается оптимизация его работы – используется JIT компилятор (Just In Time). Этот компилятор занимается тем, что при первой загрузке кода на MSIL, преобразует его в реальные команды процессора и в дальнейшем Ваше приложение будет использовать уже не MSIL, а полученный код.

Цитата(arilou @ 16.7.2004, 14:37)

На текущей платформе Windows .NET действительно в конечном итоге вызывает WinAPI. А вот когда выйдет Longhorn, все станет наоборот - WinAPI будет эмулироваться средствами .NET.

Интересно посмотреть как высокоуровневыми средствами можно эмулировать низкоуровневый WinAPI.

Цитата(arilou)

что WinAPI развиваться дальше не будет, а вся ОС будет работать в managed среде.

Они вроде собираются полностью переписать весь API, вроде будет называться WinFX.

Цитата

Интересно посмотреть как высокоуровневыми средствами можно эмулировать низкоуровневый WinAPI.

Ну приложение обращается к .NET, а .NET в свою очередь к API, что мешает "интегрировать" в среде исполнения .NET функции, которые дает WinAPI...

Цитата(Vex @ 9.2.2005, 23:11)

Они вроде собираются полностью переписать весь API, вроде будет называться WinFX

Да, а еще будет такая штука, как Avalon - замена стандартному GDI. Декларативное программирование и все такое...

Цитата

А внимательнее читать не пробовал ?

Сам себе противоречишь:

Цитата(AntonSaburov @ 3.2.2004, 18:44)

И уже эта библиотека (которая работает само собой не на MSIL, а на реальных командах процессора)выполняет Ваш код.

Цитата(AntonSaburov @ 3.2.2004, 18:44)

используется JIT компилятор

Библиотека НЕ ИСПОЛНЯЕТ IL-код. Она его компилирует. Хоть и JIT.
Если я не прав не злись а объясни, ОК?

Цитата(Vex @ 10.2.2005, 01:11)

Ну приложение обращается к .NET, а .NET в свою очередь к API, что мешает "интегрировать" в среде исполнения .NET функции, которые дает WinAPI...

Дык речь шла о

Цитата(arilou @ 16.7.2004, 14:37)

WinAPI будет эмулироваться средствами .NET.

Тогда ОС надо бы назвать Windows .NET

Вся эта затея с Windows.NET (привет, Run-time error) мне кажется довольно стремной: полностью менять внутренности системы, эмулировать WinAPI и т.п. будет очень сложно даже самому Биллу
Как мне кажется, такие извращения приведут к следующему:

* Все программы, кроме .NET, уже написанные на настоящий момент (и по-любому использующие WinAPI), особенно игры, будут работать значительно медленнее (покупайте новый компьютер! ??? )

* Эмуляция естественно будет глючить (любая программа содержит ошибку, при ее устранении появляются еще две ), а значит почти все программы (см. пункт выше) по принципу наследования будут глючить (в т.ч. и Винда - еще больше)

* Эмуляция может не поддерживать очень сложных программ (как это было когда-то с эмуляцией MS DOS)

* Так как код .NET полностью защитить (в настоящее время) нельзя, то воровства кода и крякинга (MSIL - это не ASM) будет еще больше (Неужели наступает пришествие Open source)


Вот, вроде бы, все. Будет что-то еще - дополняйте.

Кстати, Мелкософт может эмуляцию эту сделать по принципу VirtualPC (который они когда-то купили ). Т.е. фактически в отдельной тормозной (поскольку виртуальной) Винде.

Это сообщение отредактировал(а) $tatic - 28.2.2005, 19:06

Цитата

полностью менять внутренности системы, эмулировать WinAPI и т.п. будет очень сложно даже самому Биллу smile

А кто тебе сказал что это будут делать?

Цитата

А кто тебе сказал что это будут делать?

Так будут или нe будут?

Это лчно мое мнение. Скорее всего - нет.

Цитата

эмулировать WinAPI и т.п. будет очень сложно даже самому Биллу

тут даже вопрос не в сложности [вполне реально], а впроизводительности, те старые преложения замедляться как минимум на 20%

Господа, а все же что будет с асемблером?

Скорее .НЕТ исчезнет, чем ассемблер!

Цитата(Domestic @ 28.2.2005, 16:40)

Так будут или нe будут?

Мне кажется, что ни чего во внутренностях переделывать не будут, просто, сверху навесят .NET и в дальнейшем будут наращивать только его возможности, все новые API публично будут доступны только через .NET сборки, например, тот же Avalon, который уже сейчас работает под Windows XP и которой будет частью Longhorn. Не ясно откуда вобще появилась идея эмуляции Win32 API, технология .NET под Windows опирается на Win32 API, а это тонны отлаженного кода, полученного большой кровью, сомневаюсь, что кто-то будет рубить сук на котором сидит.

2Петрович : низкоуровневый WinAPI !!!????

если писать прогу под DOS она будет работать везде и без API. вот только одна эмуляция от доса к сожалению осталась, DirectDraw работает без GDI. Эмуляция GDI в частности, и APi в целом не такая уж кощунственная идея... асм пока никуда не денется, а вот все надстройки над апи(VCL MFC) уже сейчас не так актуальны, в большинстве случаев они нужны для поддержки старых проектов. Сейчас нет смысла использовать эти библиотеки в новых проектах, при возможности использования сретств дотнет..

Не понимаю...

На .NET Framework не может быть сделана ОС => эмулировать (интерпретировать) будут именно байт-код, а не API. API останется и никакой эмуляции не будет. И вообще не надо пользоваться API, иначе ваши приложения будут не кросплатформенными.

Кстати, что там с .NET в Linux и в MacOS? Мне кажется воняет мертвичиной. Надо переходить на Java. Там реальная кросплатформенность, а не ее подражание. Чего стоит .NET без нее?

Во-во! Правильно говоришь. Я про енто чудо-юдо МелкоНЕТ уже забыл давно.

Цитата из Рихтера: в далеком будущем планируется, что процессор будет поддерживать IL. ЖУТЬ!

Цитата(Denn @ 1.9.2005, 08:08)

Цитата из Рихтера: в далеком будущем планируется, что процессор будет поддерживать IL. ЖУТЬ!

ИМХО не реально. В IL переменные, а не адреса. ЦП не может оперировать данными в такой абстрактной (относительно) форме.

Цитата(neutrino @ 1.9.2005, 09:30)

ИМХО не реально. В IL переменные, а не адреса. ЦП не может оперировать данными в такой абстрактной (относительно) форме.

Что такое переменная ? Адрес в памяти.

Во-первых,

Цитата(neutrino @ 31.8.2005, 23:30)

На .NET Framework не может быть сделана ОС => эмулировать (интерпретировать) будут именно байт-код, а не API.

Не ну можно было почитать немного прежде чем выражать сомнение и непонимание? Не надо называть IL байт-кодом, потому что

• 1) это разные вещи
• 2) байт-код интерпретируется, IL - компилируется! в native

IL - это не p-code из VB6, который интерпретировался при помощи VBRUNx00.DLL.

Во-вторых,
На .NET framework никто ОС писать не собирается. Вы слышали про такое понятие "уровень абстракции" ? Вы писали бизнес-приложения для платформы Windows, которые бы работали с COM+, SQL Server, BizTalk и другими серверными платформами?

API - метрв. Он не будет расширяться и дорабатываться. Он останется, как режим совместимости для старых программ. MFC, VCL и проч. упрощали работу с WinAPI, за что им большое спасибо. Как сейчас помню программы из тысяч строк кода на C, которые окно отрисовывали и мышкой в нем линии выводить позволяли под Win 3.0.

Нельзя бесконечно тюнинговать Запорожец - рано или поздно это перестанет приносить выгоду. Так же и в программировании.

А решать умозрительные задачи, типа реализовать синглтон без статиков, это пусть на олимпиадах студенты делают, алгоритмизацию свою прокачивают. В реальном мире, где программер зарабатывает созданием бизнес-приложений, это не нужно. Нужно уметь в сроки укладываться и программы стабильные выпускать. Так вот такой уровень абстракции над сервисами ОСи и дает эту возможность.

Вот.

Цитата(arilou @ 1.9.2005, 11:48)

API - метрв. Он не будет расширяться и дорабатываться. Он останется, как режим совместимости для старых программ.

Это возможно, но только не в ближайшем будущем. Для того, чтобы .NET стала действительно стОящей системой, ее еще развивать и вазвивать. Я год пишу под нее и слишком много обнаруживаю недоделок, багов, тормозов... Ждем .NET framework 2.0, можт будет по-лучше.

Цитата(Denn @ 1.9.2005, 13:28)

Я год пишу под нее и слишком много обнаруживаю недоделок, багов, тормозов...

Да ню?
Списочек пожалуйста

Я не говорю, что .НЕТ идеален, но всё-таки пока реальных недостатков я не видел.
Добавлено @ 12:38

Цитата(neutrino @ 1.9.2005, 00:30)

Не понимаю...

Точно подмечено.

Цитата(neutrino @ 1.9.2005, 00:30)

На .NET Framework не может быть сделана ОС => эмулировать (интерпретировать) будут именно байт-код, а не API. API останется и никакой эмуляции не будет. И вообще не надо пользоваться API, иначе ваши приложения будут не кросплатформенными.

У Windows есть такая вещь как ядро, которое выставляет наружу свой интерфейс -- WinAPI.
Теперь интерфейсом к ядру будет .NET.
По-моему, очевидно

Цитата

Списочек пожалуйста

Да сейчас только некорректно наследуется форма, контролы невозможно нормально разместить на наследованной - они располагаются непонятно как после компиляции.

Тормозит. MFC очевидно быстрее в большинстве случаев.

В C# нет некоторых вещей - шаблонов, например, вроде как есть 2.0.

Некоторые исключения не ловятся - например, обращение по null указателю иногда продолжает выполнение.


Продолжу позже... Когда всплывет очередное...

Цитата(Denn @ 1.9.2005, 14:27)

Некоторые исключения не ловятся - например, обращение по null указателю иногда продолжает выполнение.

Хмм... Маловероятно.

Единственное, где я видел, что исключения не ловятся вообще -- так это в обработчике событий ActiveX объекта. Помню долго не мог найти этот глюк, а потом пришлось принять как факт.

Цитата(Denn @ 1.9.2005, 14:27)

В C# нет некоторых вещей - шаблонов, например, вроде как есть 2.0.

Вот именно. Будет. Они особо-то и не нужны. Типизированные контейнеры делаются очень легко и без них

Цитата(Denn @ 1.9.2005, 14:27)

Тормозит. MFC очевидно быстрее в большинстве случаев.

Это совсем разные вещи. Нечего сравнивать.

Цитата(Denn @ 1.9.2005, 14:27)

Да сейчас только некорректно наследуется форма, контролы невозможно нормально разместить на наследованной - они располагаются непонятно как после компиляции.

Переустанавливаем драйвера рук и головы -- всё будет Ок
Добавлено @ 13:34
По поводу последнего.
Загляни Windows Form Designer Generated Code и посмотри внимательно каким именно способом в .NET создаются формы. Тогда и поймёшь

Цитата

Хмм... Маловероятно.

Что не было такого - отлаживаешь строчка за строчкой, а на строке, где указатель null отладка прерывается и выполнение приложения продолжается?

Цитата

Вот именно. Будет.

Мда ждем...

Цитата

Это совсем разные вещи. Нечего сравнивать.

А почему бы и не сравнить скорость выполнения однотипных приложений?

Цитата

Загляни Windows Form Designer Generated Code и посмотри внимательно каким именно способом в .NET создаются формы. Тогда и поймёшь

Я понимаю как создаются формы. А ты пробовал когда-нить менять этот сгенеренный код? Лучше не пытаться. И не редактировать имена сгенеренных переменных в начале исходника.

Цитата(Denn @ 1.9.2005, 15:31)

Я понимаю как создаются формы. А ты пробовал когда-нить менять этот сгенеренный код? Лучше не пытаться. И не редактировать имена сгенеренных переменных в начале исходника.

А мне это никогда не было нужно
Зачем извращаться-то. Наоборот, я как-то долго матерился, когда увидел, что один из моего проекта вручную отредактировал сгенерённый код.
Вообще надо стараться не злоупотреблять дизайнером форм, а генерировать в рантайме.

Цитата(Denn @ 1.9.2005, 15:31)

А почему бы и не сравнить скорость выполнения однотипных приложений?

Заказчика волнует больше скорость разработки, а не скорость выполнения. Тут MFC нельзя сравнивать с .NET


Что-то мы наоффтопили тут...

Это сообщение отредактировал(а) Дрон - 1.9.2005, 14:40

Цитата(Denn @ 1.9.2005, 13:27)

Да сейчас только некорректно наследуется форма, контролы невозможно нормально разместить на наследованной - они располагаются непонятно как после компиляции.

Много раз так делал и никогда не было проблем.

Цитата(Denn @ 1.9.2005, 14:31)

где указатель null отладка прерывается и выполнение приложения продолжается?

Что такое указатель ? Ты имеешь ввиду ссылку? Тож не видел. Скорее всего, сырцы были модифицированы, но не было перекомпиляции.

Цитата(Denn @ 1.9.2005, 14:31)

А ты пробовал когда-нить менять этот сгенеренный код?

А вот этого никогда не стоит делать. На то код и сгенерированный. Если тебе надо что-то поменять в сгенерированном классе - наследуешься от него и меняешь. Вот так вот.

Кстати, и в MFC лезть руками в сгенерированный код - себе дороже выйдет.

Цитата

Заказчика волнует больше скорость разработки, а не скорость выполнения

Согласен.

Цитата(arilou @ 1.9.2005, 16:49)

Много раз так делал и никогда не было проблем.

Это вылазит иногда, если форма нагружена контролами.

Цитата(arilou @ 1.9.2005, 16:49)

Что такое указатель smile ? Ты имеешь ввиду ссылку? Тож не видел. Скорее всего, сырцы были модифицированы, но не было перекомпиляции.

Да, ссылка. Скомпиленные, конечно. В run-time такое видно, как если бы функция не отработала.

Цитата(arilou @ 1.9.2005, 16:49)

А вот этого никогда не стоит делать. На то код и сгенерированный. Если тебе надо что-то поменять в сгенерированном классе - наследуешься от него и меняешь. Вот так вот.

Я знаю, что не надо. А зачем тогда этот код, сгенеренный компилятором, лежит в исходнике? Пусть тогда в .resx будет.

Цитата(Denn @ 1.9.2005, 20:12)

Я знаю, что не надо. А зачем тогда этот код, сгенеренный компилятором, лежит в исходнике? Пусть тогда в .resx будет.

Бред полный. Код, сгенерированный дизайнером, отлаживается точно так же как и любой другой код.

Цитата

Что не было такого - отлаживаешь строчка за строчкой, а на строке, где указатель null отладка прерывается и выполнение приложения продолжается?

Если и бывают подобные проблемы - всё дело в том, что в директории с исполняемой программой отсутствуют PDB-файлы для исходников, в которых возникло исключение. Лечится сие выставлением опции "отлавливать все .NET-исключения" (сочетание клавиш Ctrl+Alt+E, поставить красный крестик напротив "Common Language Runtime Exceptions"), и "подкидыванием" pdb-файлов для всех длл-ок в директорию с программой. В этом случае, если уж приаттачишься к процессу - точно не пропустишь ни одного исключения.

З.Ы. приаттачитсья к процессу можно с пом. Ctrl+Alt+P.

Цитата(mr @ 1.9.2005, 23:04)

Бред полный. Код, сгенерированный дизайнером, отлаживается точно так же как и любой другой код.

если он предназначен только для отладки, его можно было бы как-нить защитить от редактирования.

Цитата(mr @ 1.9.2005, 23:04)

Лечится сие выставлением опции "отлавливать все .NET-исключения" (сочетание клавиш Ctrl+Alt+E, поставить красный крестик напротив "Common Language Runtime Exceptions"), и "подкидыванием" pdb-файлов для всех длл-ок в директорию с программой

спасибо, посмотрю.

Ладно. На это надо тему отдельную заводить.

Это сообщение отредактировал(а) Denn - 2.9.2005, 10:07

Интересно а что будет с драйверами? Будут новые драйвера под .NET или подойдут старые виндовские в новой винде... или тоже в эмуляции будет все? )

Цитата(Hidrag @ 11.9.2005, 07:23)

Интересно а что будет с драйверами? Будут новые драйвера под .NET или подойдут старые виндовские в новой винде... или тоже в эмуляции будет все? )

По крайней мере эта версия Windows (Vista aka Longhorn) построена на старом ядре (WinXP), поэтому и дрова будут старые, вроде.

Народ, присоветуйте...
Я немного программирую на Visual C++ 6.0, на какую систему мне лучше переходить: на С++.NET или на C#.NET А то я уже весь в растерянности
Кстати, это правда, что на С++.NET легче работть с контролами диалогами и т.д и т.п.

1. на с#.
2. мс++.нет умрёт.
3. неправда, наоборот сложнее
4. один топик - один вопрос
5. это уже неоднократно обсуждалось

Понять то поняли, но тормозим как это с делать.. подскажите пожалуйста. где ее взять как ее устанавливать?))

заходим на саит к MS, находим .NET Framework 1,1 (там ещо и обдеиты имеются) и/или 2,0, качаем, инсталируем.

OS на C#:
Singularity OS

будущее шарпа:
Phoenix Framework
Advanced Compiler Technology
Polyphonic C#
C omega
Spec#

Как вам такие наработки?

Главное - не красивое название, а практическая польза. Пока что ничего нового не предлагается (разве что датасеты превратили в часть языка и обозвали Linq-ом )

mr.DUDA, не скажи. Например, Singularity OS - это другой подход к разработке ОСи

я грю про "C omega", XLinq, DLinq, blablabla-Linq...

LINQ не трожь . Мне очччень понравился DLinq.
Добавлено @ 14:16
Это гораздо лучше, чем типизованные датасеты, по крайней мере.

В этих языках интересен не только LINQ. Там есть такие штуки как асинхронные вызовы функций и свойств, ключевые слова requires ... otherwise ..., ensures, expose, assert и т.п. Это я про Spec#, остальное еще не смотрел

Однако-ж ты меня заинтриговал! Качаю

На самом деле функциональность Spec# реализуется штатными средствами С#, но более коряво.

Даже более того, средствами асемблера ))
Вопрос только лишь в стоимости применения того или иного функционала.

Бред какой, драйверы на .Net... Долго смеялсо Вот до чего уже неокрепшие молодые умы додумались
Шучу, шучу;)
Обычные там драйверы, на C\С++ написанные, как и вся ОС Старые драйверы(Win XP) подходят прекрасно и к Windows Vista.

Singularity OS вся на .NET

Exception, я так и знал, что ты это скажешь

Привет всем !!!

Насколько я знаю и слышал есть два вида програмирования под .NET:
1. Windows Form
2. програмирование под WEB

Я шас пишу на С# (под Windows), но меня также интересует второй пункт, так как над первым пунктом я сейчас работаю...
Хотелось бы узнать побольше о програмировании под WEB, что это такое и с чем его едят.....
Так как на С# можно писать и под WEB, хочу о  нем узнать больше, может в будущем займусь всем этим.

Зарание благодарен !!!
 

за что?    

nettitan
Для начала изучи HTML и JavaScript, потому что без них "програмирование под WEB" как сапожник без сапог.    

А у мя такой аопрос: можноли компилить программу на C# не в IL-код а в native сразу? любапытно ж черт возьми    

Мнэээ... внутренний голос подсказывает, что только из MC++ можно компилить native код    

kaa
Низя. 

kaa, а зачем ?


Воистину так, аминь    

Могу предложить массу вариантов ответа. 

А как же MC++?   Стопудово где-то читал, что оттуда можно компилить native код 

C++/CLI только. Можно, конечно. 

Вот это я новость нашел, радуйтесь братья мои.....    

"Мне кажется, что переименование WinFX в .NET v3.0 вполне разумно, но я ни встречал ни одного упоминания, значит ли это, что в состав пакета будут включены C# 3.0 и LINQ, не говоря уже о DLINQ и ADO.NET v3.0. Похоже, что .NET v3.0 выйдет скорее, нежели C# 3.0 и ADO.NET v3.0, и не похоже, чтобы последние были выпущены раньше; итого, значит ли все это очередную задержку WinFX, или надо ли нам ожидать, что все другие продукты будут переименованы в 3.х или вообще в 4.0? Извиняюсь за игнорирование VB, но с тех пор как он не носит имени 3.0, то и не возникает проблемы с переименованием или задержкой выхода."


 

Он носит имя VB 9.0

Добавлено @ 17:53 


Это почему же? 

А вот возник вопрос. Существует-ли в C#.NET вариант компиляции сразу в бинарный код с включением внего всех необходимых библиотек и функций? 

Насколько мне известно нет. 

  Нет, не существует, не реализовано  
P.S. Уже тысячу раз обсуждалось!!!!! 
P.P.S. Модераторы: Предлогаю попросить у Вовы (илу у кого там просят, dm9? ) добавить в шапку раздела большими буквами:

Красными, жирным....