пятница, 1 июля 2011 г.

Как востановить поврежденный файл данных Outlook

Однажды, после неудачной синхронизации со смартфоном (я в это время еще игрался с Search Folders) Outlook меня порадовал вот таким сообщением:

clip_image002

Признаюсь, меня чуть кондратий не хватил – у меня там и почта и митинги и таски.

Как ни странно, но никакие рестарты (а именно это и советуется в сообщении об ошбике ;)) ему не помогли.

Традиционый совет, который я нашел в интернете, в подобном случае – запусить запустить Outlook c командой /resetnavpane тоже к результату не привел. Что вобщем-то и логично. Поскольку проблема не в кривом размещении окон, а в поврежденном файле данных Outlook. Какой-либо другой команды по рестарту Outlook c востановлением у Outlook тоже не обнаружилось (официальный список команд здесь).

После целенаправленных поисков по востановлению файла данных Outlook нашел ссылку на Inbox Repair Tool (Scanpst.exe).

Хоть название утилилты не особо вселяло надежду (у меня грохнулся не просто Inbox, а весь файл с почтой, календарем и пр.), програму я нашел и запустил. У меня она располагается здесь "C:\Program Files (x86)\Microsoft Office\Office12\SCANPST.EXE".

clip_image004

Файл сканировался больше часа (а что ж вы хотели пару гигов то ;)) и к моему счатью ему помогло.

Пару выводов из всей этой истории:

1. Совет в сообщении об ошибке 'Microsoft Office Outlook' must be restarted – что мертвому припарка. Лучще бы сразу советовали запустить сканирование Scanpst.exe, если поврежден файл данных.

2. Inbox Repair Tool стоит переназвать. Что-то вроде Outlook Data File Repair Tool куда больше соответсвует действительности.

3. Такую ценную утилиту стоит выноить в Start Menu.

4. Ну и последнее. Не настраивайте Search Folders во время синхронизации с Outlook ;).

среда, 22 июня 2011 г.

Использование C# кода и объектов расширения (extension objects) в XSLT-процессоре .NET Framework

В .NET реализована спецификация XSLT 1.0 и его возможностей за частую не хватает. Например, отсутствует использование регулярных выражений, нет кодирования строк для использования в URL и т. д. В то же время .NET Framework позволяет обойти ограничения за счет таких средств как:
  1. параметры XSL трансформации;
  2. встраивание кода на JavaScript, VB.NET, C# и других языках;
  3. использование объектов расширения (extension objects.

В этой статье я хочу остановиться только на 2-х способах, которые сам регулярно использую, внедрение кода на С# и объекты расширения. Чтобы примеры были более конкретными, допустим, что у нас есть XML файл в котором содержатся данные для формирования линки на поиск в Bing. Вот пример такого XML файла:

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

Вот пример такого XML файла:

    xml version="1.0" encoding="utf-8" ?>

    <queries>

    <query title="A & B" term="A & B"/>

    queries>

Если в такого рода задаче не кодировать параметры для URL, то специальные символы (как &) не будут закодированы и URL будет распознан не верно либо может сформироваться невалидный URL.
Ниже приведен пример поиска по запросу из XML файла без кодирования параметров

    clip_image002

А здесь правильный вариант

    clip_image004

В первом случае символ & не был закодирован и не распознан, как часть строки поиска. Во втором случае & был закодирован и Bing распознал его.

Ниже приведены примеры, как можно добавить кодировние URL внедрением C# кода и с использованием объектов расширения. Фрагменты C# кода и XSLT на которые надо обратить внимание, выделены жирным и увеличенным шрифтом.

Пример XSLT с внедрением С# кода

    xml version="1.0" encoding="utf-8"?>

    <xsl:stylesheet

    version="1.0"

    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

    xmlns:msxsl="urn:schemas-microsoft-com:xslt"

    xmlns:utility="urn:utility-scripts"

    exclude-result-prefixes="msxsl">

    <xsl:output method="html" indent="yes"/>

    <xsl:template match="query">

    <xsl:element name="a">

    <xsl:attribute name="href">

    <xsl:value-of select="concat('http://bing.com/search?q=', utility:EncodeUrl(@term))"/>

    xsl:attribute>

    <xsl:value-of select="@title"/>

    xsl:element>

    <br />

    xsl:template>

    <msxsl:script language="C#" implements-prefix="utility">

    <msxsl:assembly name="system.web" />

    public string EncodeUrl(string rawUrl) {

    return System.Web.HttpUtility.UrlEncode(rawUrl);

    }

    ]]>

    msxsl:script>

    xsl:stylesheet>

Пример с использованием объектов расширения
XSLT:

    xml version="1.0" encoding="utf-8"?>

    <xsl:stylesheet

    version="1.0"

    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

    xmlns:msxsl="urn:schemas-microsoft-com:xslt"

    xmlns:utility="urn:utility-scripts"

    exclude-result-prefixes="msxsl">

    <xsl:output method="html" indent="yes"/>

    <xsl:template match="query">

    <xsl:element name="a">

    <xsl:attribute name="href">

    <xsl:value-of select="concat('http://bing.com/search?q=', utility:EncodeUrl(@term))"/>

    xsl:attribute>

    <xsl:value-of select="@title"/>

    xsl:element>

    <br />

    xsl:template>

    xsl:stylesheet>

Вызывающий C# код:

    class Program

    {

    static void Main(string[] args)

    {

    XslCompiledTransform xsltAndExtObjTransform = new XslCompiledTransform();

    xsltAndExtObjTransform.Load("..\\..\\XsltAndExtObj.xslt");

    XsltArgumentList arguments = new XsltArgumentList();

    arguments.AddExtensionObject("urn:utility-scripts", new Program());

    using (StreamWriter writer = File.CreateText("XsltAndExtObj.html"))

    {

    xsltAndExtObjTransform.Transform("..\\..\\Data.xml", arguments, writer);

    }

    }

    public string EncodeUrl(string rawUrl)

    {

    return System.Web.HttpUtility.UrlEncode(rawUrl);

    }

    }


Заключение
Описанные методы дают огромные возможности для расширения возможностей XSLT, но нужно помнить, что есть и плата – это потеря некоторой переносимости кода. Такой XSLT не возможно без переработки использовать в среде отличной от .NET – таких как Java или PHP и т. д.

Если же сравнивать межу собой внедрение c# кода и объекты расширения, то предпочтительней использовать объекты расширения. Их проще разрабатывать – есть подсветка синтаксиса и синтаксические ошибки выявляются на этапе компиляции проекта . Проще сопровождать – можно (и нужно) написать unit-test для проверки логических ошибок. Ну и на конец объект расширения можно будет использовать повторно (и не только в XSLT).

Удобство в использовании объектов расширения в том, что весь код, необходимый для их работы находится в том же XSLT файле. Без каких либо дополнительных усилий и зависимостей, XSLT c объектами расширения можно использовать в другой трансформации, другом .NET проекте.

В завершение статьи, тем кого заинтересовала данная тема хочу посоветовать посмотреть соответствующий раздел MSDN, где достаточно подробно описаны возможности расширения XSLT.

вторник, 7 июня 2011 г.

Эрик Гамма переходит на работу в Майкрософт

Как пишет в своем блоге Janson Zanders, признанный эксперт в области разработки программного обеспечения, соавтор книги Design Patterns, один из разработчиков JUnit и Eclipse -- Эрик Гамма присоединится к команде разработчиков Visual Studio и возглавит Visual Studio development lab в Цюрихе. Подробнее здесь.

понедельник, 6 июня 2011 г.

Незаменимых нет? (или чем заменить .NET Reflector)

Многие знают, что с июня месяца рефлектор стал платным. За неделю до этого события я решил подыскать себе бесплатную альтернативу. Выбирал среди ILSpy, JetBrains dotPeek и Telerik JustDecompile. Около недели я ими пользовался, и свои наблюдения я фиксировал в файлике. Таким образом, у меня появилась небольшая статья, которая, возможно, кому-нибудь облегчит выбор.

С основной задачей – декомпиляцией кода все приложения справляются достаточно хорошо. Поэтому следующим шагом стал выбор наиболее удобной в использовании замены рефлектора и развитость «второстепенного» функционала.

Наиболее важные для меня критерий выбора декомпилятора были следующие:

  1. Удобство работы
  2. Скорость работы (загрузка, поиск типа, декомпиляция)
  3. Функционал
    1. Analyze
    2. Декомпиляция в Visual Basic
    3. Search MSDN
    4. Поиск типа, метода, строки.

Естественно, поскольку, удобство работы, это очень нечеткий критерий, то и вывод мой, что мой вывод будет субъективным.

По скорости работы особых нареканий у меня тоже не оказалось. Точнее все работают приблизительно одинаково медленно ;), разве что Telerik JustDecompile грузится немого медленей других.

А вот по развитости второстепенного функционала продукты отличаются довольно сильно.

К сожалению, на текущий момент ни один из декомпиляторов не поддерживают следующие операции:

  • Поиск строки
  • Поиск выбранного типа в MSDN
  • Поиск выбранного типа в Bing

Однако, что поскольку разработка этих продуктов началась сравнительно недавно (февраль 2011) и еще идет полным ходом, функционал может существенно измениться. Поэтому ниже я привожу версии продуктов, между которыми я выбирал.

Далее я приведу скриншоты декомпиляторово и их краткое описание (отличие).


ILSpy билд 1.0.0.822

image

Очень похож на.NET Reflector. Умеет декомпилировать в C# и IL. Есть приятная функция, которой нет в рефлекторе и в других декомпиляторах – при декомпиляции кода показывает комментарии, что очень удобно.

Единственный из продуктов, который позволяет пометить сразу несколько сборок для удаления.

Telerik JustDecompile Beta билд 2011.1.516.2

image

Минусы начинаются со скачивания инсталлятора – при скачивании требует регистрации. У меня регистрация была, но в противном случае я бы его не стал скачивать.

Интересное совпадение, пока я писал эту статью JustDecompile показал мне уведомление, что есть обновленние, но что бы его скачать надо было опять вводить регистрационные данные. Лень мне стало их искать и обновление не стал скачивать.
Переборщили они с этим.

Немного не типичный интерфейс пользователя из-за чего создается впечатление что у программы Из рассматриваемых продуктов единственный, который на текущий момент умеет декомпилировать в C# и Visual Basic .NET.

Функция Analyze здесь называется Find Usages. Есть проблемы с поиском типов. Почему-то не всегда находит типы, так же не всегда при поиске типов фокус ввода в поле ввода. Мелочь, а неприятно.

JetBrains dotPeek билд 1.0.0.1219

Наиболее глючный и в то же время наиболее функциональный продукт. Регулярно (но не так часто чтобы надоесть) показывает диалог с просьбой отправить детали ошибки. Несколько раз сталкивался с таким багом. Открываю, например, исходники StringBuilder, затем выбираю интерфейс, который он реализует и исходный текст StringBuilder’а пропадает и больше не появляется. Ниже наглядная демонстрация бага.

image

Из существенных ограничений – умеет только декомпилировать в C#.

Для тех, кто пользуется решарпером интерфейс и горячие клавиши будут знакомы. Жаль, но не работает как в решарпере поиск элемента по заглавным буквам. Отличается и немного терминология. Т.е. нет команды Analyze, но есть Find Usages и Find Usages Advanced.

Нет панели инструментов с кнопками навигации (как-то привык я к нему в рефлекторе), чтобы перемещаться по коду вперед-назад надо выбирать пункта Navigate главного меню, что откровенно говоря не удобно. К счастью для этих команд горячие клавиши такие же как и в студии по дефолту.

Автоматически не выделяется текущий тип в дереве (но есть специальная команда ;)).

Как видно из скриншота каждый тип открывается в новой вкладке. Вкладки можно перемещать и прикреплять аналогично тому как это делается в студии.

Из интересных новшеств подметил, что dotPeek умеет подгружать с сайта Майросовт реальный исходный код (как это делает студия), но у меня почему-то это не сработало (возможно, тоже какой-то дефект).

Выводы

Меньше всех понравился JustDecompile. Оставлю только на случай если понадобится декомпиляция в Visual Basic .NET. Между ILSpy и dotPeek окончательный выбор я так пока не сделал. Я хоть и пользусь решарпером и нравится мне продвинутая функциональнось dotPeek, но как-то в большинстве случаев ILSpy пользоваться удобней. Возможно, сказывается привычка к .NET Reflector, а ILSpy больше всего на него похож.

пятница, 13 мая 2011 г.

Офисный фитнес

Пятница навеяла.

Один из краеугольных камней таймменеджмента – это отдых. Отдыхать надо регуляно и правильно Smile. Правильный отдых для программистов – это не чтение новостей и блогов под кружку чая или кофе (как многие из нас любят делать), а какая-либо физическая нагрузка.

Я стараюсь поступать так. Накапливаю мелкие задачи, чтобы выполнить во время отыха: занести справку в бухгалтерию, отнести админам диск, распечатать что-либо на принтере (принтер в другой комнате). Но любимый мой способ отдыха – это ходьба по лестнице. Поднимаюсь на 7-9 этажей, спускаюсь, и т.п, Темп и количество этажей зависят от настроения.

Заметил интересный побочный эфект. Во время ходьбы по лестницевспоминается что-то что хотел бы сделать, но нигде не записал, приходят интересные идеи (но как правило не связанные с работой Smile). Всем хорошего отдыха!

пятница, 8 апреля 2011 г.

Если хочешь что-то спрятать – положи на видном месте

В продолжение темы залоченных файлов. Совершенно случайно обратил внимание что оказывается стандартный диалог File In Use показывает имя процесса, который держит файл. Жаль что не позволяет его разлочить и не работает для каталогов.

Ниже скриншот с моего прошлого поста

image

четверг, 3 февраля 2011 г.

Как узнать, кто заблокировал файл или папку

Я регулярно пользуюсь утилитами Sysinternals и хочу поделиться одним из cпособов как при помощи Process Explorer выяснить какой процесс заблокировал доступ к файлу или папке.

Использовать утилиты очень удобно – они бесплатны, не требуют инсталляции и могут быть запущены без предварительного скачивания из интернета (см http://live.sysinternals.com/). Последние 2 пункта делают их очень удобными при анализе и устранении проблем на серверах.

Я недавно завел Ютуб-канал, где выкладываю видео по теме блога. Приглашаю Вас посмотреть и подписаться что бы не пропустить новые выпуски.



Итак, как же узнать, кто держит тот или иной файл или папку.

Для скриншотов я смоделировал такую ситуацию нарочно, открыв в Word файл "D:\temp\Doc1.docx" и пытаясь его в это же время удалить в проводнике. При попытке удалить файл получаю следующее сообщение

image

Поищем этот документ в Process Explorer: Find->Find Handle or DLL…

В появившемся окне вводим имя заблокированного файла и жмем Search

image

Двойной клик на найденном файле и вы переходите в дерево процессов.

В нижем списке выбираете ваш файл (он подсвечен серым) и в контекстном меню выбираете команду Close Handle. Соглашаетесь с предупреждением, что приложение может упасть и все. Файл разблокирован и может быть спокойно удален.

Есть еще один способ сделать то же самое – воспользоваться утилитой Unlocker. Она тоже бесплатна и ее можно скачать с сайта разработчика http://cedrick.collomb.perso.sfr.fr/unlocker/.

Утилита требует инсталляции . После инсталляции, в проводнике, в контекстном меню появится пункт Unlocker.

Выделяете в проводнике проблемный файл, выбираете команду Unlocker и в появившемся окне видно какой процесс заблокировал файл. Кнопка Unblock разблокирует файл и можно его будет спокойно удалить.

image

Это конечно проще чем с Process Explorer :). Еще один плюс – если файл нельзя удалить сразу, например какой-нибудь системный файл, то Unlocker может предложить его удалить во время перезагрузки системы.

суббота, 22 января 2011 г.

И снова здравствуйте!

Друзья!

Более двух лет в блоге не было ни одного сообщения. Как верно заметил BrigOS, в одном из комментариев, по сути блог был мертв и его можно было удалить из RSS ридера. Но блог не умер, он просто спал и набирался сил.

За два года много изменилось – айфоны и айпэды захватили мир, а Live Search стал Bing. Изменилась и моя жизнь – у меня родился сын (и ему уже почти 2 года ;)), немного изменились и мои увлечения. Что бы успевать больше я стал верным адептом тайм-менеджмента и появилось время для ведения блога. Более того, появилось большое желание снова его вести. Возможно, немного изменится тематика блога – по мимо чисто програмистских тем, мне хочется поделисться опытом применения тайм-менеджмента в собственной жизни, появятся отзывы на прочитанные книги. Планируемая периодичность обновления блога – раз в 2 недели.

До следующей встречи!