22 мая 2009 г.

Не закрывается процесс Excel.exe, созданный через Interop.Excel?

Никак не вычищается из памяти Excel.exe? Даже делаете все по шагам из статьи Office application does not quit after automation from Visual Studio .NET client? Уже решили убивать все весящие Excel-процессы командой Kill?

Я тоже несколько раз заходил на решение этой проблемы, но никак не мог понять, почему процесс Excel.exe никак не хочет вылезать из памяти? Между тем генерация Excel или Word документов частенько требуется в различных проектах.

Вопрос на засыпку: в какой строке будет утечка памяти?

   1:  Application application = new Application {Visible = false};
   2:  Workbook workbook = application.Workbooks.Add(Type.Missing);
   3:  Worksheet sheet = (Worksheet) workbook.ActiveSheet;
   4:   
   5:  ...
   6:   
   7:  sheet.Cells[1, 1] = "columnTitle";
   8:  sheet.Cells[1, 1].EntireColumn.AutoFit();
   9:   
  10:  ...
  11:   
  12:  Marshal.ReleaseComObject(sheet);
  13:   
  14:  workbook.Close(false, Type.Missing, Type.Missing);
  15:  Marshal.ReleaseComObject(workbook);
  16:   
  17:  application.Quit();
  18:  Marshal.ReleaseComObject(application);

Те, кто прочитал Office application does not quit..., смело скажу во 2ой и буду абсолютно правы. Те, кто нашли GOTCHA: Com Interop, захотят исправить код на:

   1:  Application application = new Application {Visible = false};
   2:  Workbooks workbooks = application.Workbooks;
   3:  Workbook workbook = workbooks.Add(Type.Missing);
   4:  Worksheet sheet = (Worksheet) workbook.ActiveSheet;
   5:   
   6:  ...
   7:   
   8:  Range range = sheet.Cells;
   9:  range[1, 1] = "columnTitle";
  10:  range[1, 1].EntireColumn.AutoFit();
  11:   
  12:  Marshal.ReleaseComObject(range);
  13:   
  14:  ...
  15:   
  16:  Marshal.ReleaseComObject(sheet);
  17:   
  18:  workbook.Close(false, Type.Missing, Type.Missing);
  19:  Marshal.ReleaseComObject(workbook);
  20:   
  21:  Marshal.ReleaseComObject(workbooks);
  22:   
  23:  application.Quit();
  24:  Marshal.ReleaseComObject(application);

И все бы хорошо, только строчка 10 до сих пор "протекает". Исправить это можно так:

   1:  ...
   2:   
   3:  var currentCell = (Range)range[1, 1];
   4:  Range entireColumn = currentCell.EntireColumn;
   5:  entireColumn.AutoFit();
   6:   
   7:  Marshal.ReleaseComObject(entireColumn);
   8:  Marshal.ReleaseComObject(currentCell);
   9:   
  10:  ...

В комментариях несколько полезных советов по этой теме...

19 мая 2009 г.

Наши инструменты и приемы для TDD

Путь, который должен пройти настоящий TDD-программист тернист и опасен. Чтобы не пасть духом и не повернуть назад, понадобится специальное снаряжение. Инструменты TDD-программиста должны быть легки, чтобы он мог преодолевать препятствия не уставая, и заточены как лезвие, чтобы смог справиться с любыми трудностями.

18 мая 2009 г.

Комментируем по-русски

С недавних пор мы начали писать все комментарии в проекте по-русски. Все начиная от XML-комментариев, заканчивая комментариями к коммитам.

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

Что произошло? Можно сказать свершилась моя голубая мечта. Раньше частенько попадались немногословные комментарии к коммитам типа change, delete junk, fix bug. Сейчас все пишут развернутые комментарии! Бывает даже в несколько предложений. Например, "HtmlHelperExtensions - добавил создание статического листа InquiryUnitDropDownList для отображения списка единиц измерения в заявке на продукт"

Видимо, для написания этой фразы на английском не хватало терпения и знания языка.

14 мая 2009 г.

Делаем XML-комментарии обязательными

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

После выставления этих опций в свойствах проекта на каждый публичный объект без XML-комментария (класс, метод, свойство и т.д.) выдается ошибка компиляции:

Надеюсь, что этот пример поможет вам, если вы, как и я, пытались внедрить в команду культуру написания XML-комментарием.

8 мая 2009 г.

TDD и LLBLGen Pro v 2.0

Сейчас мы активно используем ORM LLBLGen Pro в своих проектах. Я уже рассказывал, как мы решили проблему с тестированием DataAccessApater и запросов на Linq, которые по своему реализованы в этой ORM.

6 мая 2009 г.

Смещение акцентов

Артем Смирнов в статье База, знай свое место! выразил свое мнение по поводу места базы данных при разработке ПО. Даже назвал ее "простой утилитой". Заявления довольно резкие и стоят прояснения.

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

Чем будет обусловлен выбор? Главное здесь это то, что в последнее время произошло смещение акцентов при разработке ПО. Разработчики и менеджеры стараются больше внимания уделять сопровождению приложения, его развитию в долгосрочной перспективе. Именно поэтому основное внимание (опять же не всегда) уделяется развитию и поддержанию гибкого и понятного дизайна в коде. С таким кодом проще работать, он содержит меньше ошибок, искать ошибки проще, новые программисты могут быстрее разобраться в исходном коде и приступить к работе в команде.

4 мая 2009 г.

Шаг вперед, шаг назад

После последнего отчета The Standish Group "CHAOS Summary 2009" я нашел их предыдущие публикации и посмотрел развитие нашей отрасли за 15 лет.

На фоне постоянно улучшающихся технологий, создания новых методик разработки ПО рост незначительный. Возможно проблема не в технике, а в головах? Причем обвинять одних разработчиков и менеджеров в том, что они слишком инертные или не хотят расти над собой будет неправильно. Люди, которые выставляют бизнес-цели, причастны к провалам в такой же степени, как и исполнители.

Сами учредитель компании The Standish Group видят улучшение в индустрии производства ПО и являются большими поклонниками гибких методологий. Продвигаться вперед небольшими шагами - итерациями - вот возможное решение, которое снижает риски проекта оказаться в числе повалившихся.

3 мая 2009 г.

Ускоряем сборку проектов в Visual Studio

При компиляции вашего проекта Visual Studio должна собрать больше 20 проектов? Значит вы, как и я, уже заметили, что эта операция занимает прилично времени. Сейчас у нас за раз компилируется 27 проектов и мы нашли способ, как ускорить этот процесс.