недетское вскрытие .NET

N|M{INT3 TEAM}{NIM@INT3.RU}

Спецвыпуск: Хакер, номер #066, стр. 066-044-2

Однажды, когда я написал собственный IL-дизассемблер, мне потребовался такой .NET-контрол, который выделял бы пространства имен, классы и методы в отдельные структуры Nested Tables. Стал искать подходящий. Нашел много красивых, удобных, но ни один из них не реализовывал Virtual Render Control. Как результат, большие потери памяти, медленная прорисовка и невозможный скроллинг. К примеру, при дизассемблировании стандартной библиотеки mscorlib.dll и отображении в XceedGrid было растрачено 1450 Мб памяти, элементы добавлялись 40 минут, а рендеринг происходил за 45 секунд. Где это видано? Когда я написал службе технической поддержки, мне посоветовали привести все вложенные элементы в свернутый вид. Что же получается? Я должен постоянно щелкать на нужных элементах, что обламывает — лучше уж покручу третью кнопку мыши, удобнее будет. Впрочем, и остальные Grid’ы не отличались могучей производительностью.

Сейчас пошла мода на поддержку дизайнера форм, но зачем делать ее для элемента? Я никогда так и не пойму этого. Лишний раз затрачивается память, притом затраты умножаются на количество элементов! По возможности я стараюсь вынести поля класса (константы) из элемента куда-нибудь в статику, чтобы он занимал меньше памяти и работал быстрее. Ясно, конечно, что красота (точнее, красота и удобство разработки) требует жертв, но я всегда делаю выбор в пользу быстродействия и производительности. Из-за программистов .NET, нелепых и искушенных легкостью использования тормознутых технологий, и распространилось стойкое предубеждение о .NET как о великом тормозе. Как бы не так! Для решения проблемы мне пришлось написать собственный контрол: при отображении листинга библиотеки mscorlib.dll затрачивается всего 4,5 Мб памяти, рендер происходит за ~0,081 секунды, добавление всех элементов — ~0,8 секунд, прилагается попиксельный скроллинг. В моем Grid’e нет навороченной поддержки дизайнера форм и всяких примочек, зато он простой, быстрый и красивый.

[матчасть] Для опытов возьмем компонент C1TrueDBGrid, взятый с сайта www.purecomponents.com. Этот Grid-контрол сделан в одной из ведущих компаний по производству компонентов. Работа будет идти следующим образом. Берем любой пример, поставляемый с компонентом, компилируем его, в папке проекта находим появившуюся папку \debug\bin.

Переходим в нее, дизассемблируем:

ildasm c1.win.c1truedbgrid.DLL /out=c1.win.c1truedbgrid.h.

Для ассемблирования нужно удалить (в Studio) этот контрол из References. И только потом делать

ilasm c1.win.c1truedbgrid.h /dll /debug

Точно так же поступаем при каждом ассемблировании. Иначе при ассемблировании выйдет ошибка: Failed to write output file, error code=0x80070020. Это значит, что файл занят Studio и она не позволяет перезаписывать его. Если твои действия были правильными, ты сможешь трассировать компонент в том же окне Studio, где находится и сам пример его использования. Однако при первом запуске сразу получаем ошибку: «Сбой при проверке строгого имени для сборки 'C1.Win.C1TrueDBGrid'». Это цифровая подпись, именуемая Strong Name. В других моих статьях в этом СПЕЦе я много писал о ней, не буду повторяться. Для удаления подписи нужно закомментировать атрибуты .custom instance void [mscorlib]System.Reflection.AssemblyKeyFileAttribute::.ctor(string) и .publickey. Прошу не удалять код, лучше помещать его в комментарии.