Будни программиста

Вот такое сообщение я получил от студии, когда попытался подключиться к IE, чтобы отладить панельку, написанную на C#. Кстати, хорошая и почти единственная статья о том, как сделать свой тулбар для эксплорера, написана вот здесь: Extending Explorer with Band Objects using .NET and Windows Forms . А теперь - детально. Панель для эксплорера представляет собой так называемый COM Callable Wrapper (CCW) и была написана на .NET 1.1 в Visual Studio 2003 - аттачился я, соответственно, в ней же. Как вы уже поняли, такой способ не сработал. Затем я попытался отладить компонент при помощи другого хост-контейнера (ActiveX Control Test Container) – та же ерунда. Думаю, ладно не студия, так WinDbg. Пусть не так удобно, но на безрыбье и рак рыба. Приатачился! Собирался подгрузить SOS.dll и тут обратил внимание, что в процесс IE загрузился не .NET 1.1 a .NET 2.0! Снес с машины второй фреймворк (к счастью, у меня была такая возможность). И опа! - все хоккей, студия замечательно подключилась. По правд

Недавно, просматривая главу книги Framework Design Guidelines, посвященную событиям (event) наткнулся на интересное замечание. Это же замечание про события процитировано и на блоге Brad Abrams Events, Delegate and Multithreading . Суть его в следующем. Предположим, что у нашего класса есть некое событие Clicked, объявленное следующим образом: public event EventHandler Clicked; Если метод генерации события написан в виде: protected void OnUnsafeRaiseClick() { if (Clicked != null ) Clicked( this , EventArgs .Empty); } - это приводит к небезопасному поведению в случае многопоточного исполнения, когда один поток пытается сгенерировать событие, а второй в этот момент отписывает последний делегат. При определенном стечении обстоятельств проверка Clicked != null может пройти успешно (второй поток еще не отписал последний делегат), а попытка выполнить Clicked( this , EventArgs .Empty) может привести к исключению System.NullReferenceException (если второй пот

На днях спрашивали у меня, как внедрить в сборку текстовый файл и затем прочитать его. Вообще-то задача внедрения и получения текстового файла из сборки по сути аналогична тому, как написано в статье Сергея Розовика Как вытащить иконку из ресурса . Заметил, что эта, в общем-то, несложная задача ставит многих разработчиков в тупик (может быть это потому, что они не читают хороших блогов :-). Поэтому решил описать ее подробнее и для более общего случая. Процесс внедрения может быть описан следующими шагами: Добавляем файл как Embedded Resource. По имени файла в ресурсе получаем поток, позволяющий считать файл. Работаем с потоком, чтобы получить нужный программный объект. Например, строку с содержимым текстового файла или объект изображения/иконки. А теперь более подробно. Для внедрения файла в сборку, надо подключить его к проекту и выставить значение свойства Build Action в Embedded Resource . Теперь после компиляции файл будет внедрен в ресурсы сборки. Переходим к извлечению. Имя файл

На днях коллега попросил помочь ему разобраться в ситуации. Ситуация достаточно интересная, и поэтому я решил написать о ней в блоге. Мой коллега отлаживал приложение на тестовой машине. Он подключился отладчиком к работающему приложению, подгрузил отладочные символы (pdb -файлы) и поставил брейкпоинт в нужном ему методе. Код, который его интересовал, выглядел приблизительно так: Однако отладчик упорно игнорировал точку прерывания, хотя показывал, что отладочные символы для метода загружены. И я, откровенно говоря, был в замешательстве. Немного поразмыслив, на ум пришел тот факт, что исполнение кода в новом AppDomain приводит к тому, что в него все сборки загружаются отдельно. Отсюда я пришел к гипотезе, что в новый домен не загрузились отладочные символы. Для проверки моего предположения мы скопировали pdb-файл в тот же каталог, откуда загружалась и отлаживаемая сборка. Кстати, узнать путь реальной загрузки сборки можно либо из окна Output (View-> Output), либо окна Modules (Debug