По какой-то малопонятной мне причине адаптеры нельзя наследовать от генерик-типов. Сволочи.

Грабли, как мне кажется, есть везде. В своё время, ни одна библиотека не прошла мимо меня в проект, кроме, пожалуй, Infragistics, без доработки. Поговорим о граблях в System.AddIn.

Для начала порекомендую прочитать статью в блоге Джейсона Хи (Jason He), которая называется «Coding patterns to avoid in addin pipeline development». Да и вообще, его блог почитать надо, он поподробнее Walkthrough в MSDN.

Итак, первая грабля, на которую я наступил: дефолтные домены работают без ShadowCopy, как следствие, заменить сборки на горячем сервере мы не можем. Ок, нам особо и не надо, сделаем домен сами:

[cc lang="csharp"]
AddInStore.Update(pipelineRootFolderPath);

Collection tokens = AddInStore.FindAddIns(typeof(IView), pipelineRootFolderPath);

AddInToken calcToken = tokens[0];

AppDomain domain = AppDomain.CreateDomain(string.Format(«Test {0}», DateTime.Now), null, new AppDomainSetup { ShadowCopyFiles = «true» });

return calcToken.Activate(domain);
[/cc]

Затем мы работаем, всё ок. Для выгрузки аддона используем такой код: [cci lang="csharp"]AddInController.GetAddInController(calc).Shutdown()[/cci]. По идее всё хорошо, но есть одно но. Из-за того, что мы домен создали вручную, то автоматически инфраструктура System.AddIn его не выгрузит. Да, это может быть логично, но об этом нигде не написано.

Код ниже логичен, но будет падать, несмотря на то, что ссылка на домен у контроллера есть, и она живая. Просто разработчики посчитали, что раз AddIn отключен, то домен нам уже не нужен. Вообще, реализация AddInController’a с [cci lang="csharp"]lock(this)[/cci] и прочим меня ни разу не порадовала.

[cc lang="csharp"]
AddInController c = AddInController.GetAddInController(calc);
c.Shutdown();
AppDomain.Unload(c.AppDomain);
[/cc]

Правильный код вот такой:

[cc lang="csharp"]
AddInController c = AddInController.GetAddInController(calc);
AppDomain d = c.AppDomain;
c.Shutdown();
AppDomain.Unload(d);
[/cc]

Спасибо коллегам, отговорившим меня городить велосипед. Но монструозность System.Addin таки поражает.

Кто мне скажет, зачем выделили Views? Я вот что-то понять не могу, хватило бы адаптеров, имхо.

Минимальный проект с использованием System.AddIn

Кто будет использовать, учтите, что при отключении Addin’а последовательно вызываются

GC.WaitForPendingFinalizers();
GC.Collect();


Из-за этого придётся городить свой движок плагинов.

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

Когда же он говорит «я просто открываю файл блокнотом и мешаю логику и разметку», когда он в один проект запихивает сайт на asp.net, виндовый сервис и консольное приложение, когда всё это не компилируется и выложено как релиз, хочется пробить с ноги по яйцам. Чтобы не размножался.

Тестовый сервер жрёт теперь 600 метров памяти вместо полутора гигов. Мелочи, а приятно.

Вчера, пользуясь тем, что не мог уснуть от жары, начал кодить всякое и наткнулся на ещё один радостный прикол со стороны наших любимых опенсорсных продуктов. Но сначала отгадка для загадки про MySql (ЖЖ).

1. played = 1, avgScore = 150;
2. played = 1, avgScore = 300.

Почему так — разбираться влом, но факт остаётся фактом, запросы в mySql получаются императивными, что меня не обрадовало. Кстати, формула для avgScore достаточно проста: avg(n+1) = (n * avg(n) + a(n+1)) / (n+1).

Из новых приколов: драйвер для mySql в PDO в виндовой версии PHP с приятным багом. Более двух инсертов за одну сессию засунуть нельзя. Даже, если они заныканы в хранимку. Надо рвать/поднимать соединение заново. Или юзать стороннюю дллку, где бага нет.

Баг присуствует в таких сборках как denwer и vs.php, как минимум.

Приятной работы.

Дано: таблица T с полями id (pk, autoincrement, int(11)), played (int(11)), avgScore(int(11)). Для записи с заданным id played = avgScore = 0. Это важно.

Вопрос: чему будут равны played и avgScore для записи с этим id (пусть будет 123, неважно) после запросов:

1. update `T` set
`T`.`played` = `T`.`played` + 1,
`T`.`avgScore` = (`T`.`played` * `T`.`avgScore` + 300) / (`T`.`played` + 1)
where `T`.`id` = 123;
2. update `T` set
`T`.`avgScore` = (`T`.`played` * `T`.`avgScore` + 300) / (`T`.`played` + 1),
`T`.`played` = `T`.`played` + 1
where `T`.`id` = 123;

Обещанное продолжение про профайлеры. Начало тут

В предыдущей статье мы сделали дамп с помощью WinDbg. Далее, что с ним можно сделать? Наверно много, но меня интересовало только одно, а именно — память. Поэтому, я загнал дамп в .Net Memory Profiler.

Данный профайлер сказал мне, что из 7 гигов рама, у меня управляемой памяти всего 1.5 гига. Так как я был тупо уверен (без всяких на то указаний — это ошибка), что утечка именно в управляемой дотнетом памяти, то эту информацию я сразу отбросил и выкинул профайлер.

Пришлось гуглить и пытать по аське знакомых. Результаты:

“!eeheap -stat” — выдаст статистику по управляемым кучам. Предварительно надо загрузить расширение sos.dll. Посмотрев результаты, я понял, что управляемой памяти на самом деле всего полтора гига.

Дальнейшее было делом техники — зацепился из кода к GC Lua, стал выводить статистику по памяти в лог и убедился, что жрёт наш замечательный интерпретатор.

А вот пособие для нубов, как юзать WinDbg для отсечки утечек памяти.