Создание проектов с NuGet и ReSharper

В этом видео я рассказываю как работать с пакетами NuGet, как их комплексно устанавливать. Как пользоваться ReSharper для добавления usings и почему я никогда не указываю используемые неймспейсы. Так же расскажу о некоторых подводных камнях.

 

Hard’n’Heavy!

 

 

Внедрение Notification Bar

Сложность 100

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

Установка

Начнем с установки компонента. Это можно сделать с помощью NuGet пакета следующей командой:

Install-Package VioletTape.NotificationBar

При установке будут подгружены так же все зависимые компоненты и пакеты:

  • PostSharp Free Community Edition
  • PostSharp Threading Toolkit
  • PostSharp Domain Toolkit
  • Rx Framework
  • StructureMap
  • MakeMeAsync

Данный пакет необходимо будет установить для сборки с UI компонентами и для сборки с моделями.

UI настройка

Естественно, что для любой технологии и для любого компонента всегда есть некоторые ограничения и необходимые начальные условия. Так что предлагаю рассмотреть некоторые необходимые начальные условия для Notification Bar. На данный момент такими естественными ограничениями являются технологии:

  • .Net Framework 4.5
  • Windows Presentation Framework

Это в некотором роде базис, ограничения самой платформы. Следующее требование вам придется реализовывать самостоятельно, но это на мой взгляд минимальные ограничения на ваш продукт. Итак, необходимо реализовать интерфейс

Реализация данного интерфейса позволяет системе уведомлений переводить пользователей на нужные экраны и отслеживать текущее визуальное состояние программы. Я постарался максимально сократить требования интерфейса, чтобы максимально упростить внедрение.

В этом месте стоит остановится поподробнее и рассказать об общей системе приложений, о системе UI.

Если мы говорим о сколько-нибудь серьезном приложении, для которого собственно и понадобится система уведомлений, то скорее всего схематически оно выглядит так:

Подробнее

Notification Bar Overview

Сложность 100-200

В данном посте я хочу дать очень краткую обзорную информацию по компоненту Notificaion Bar, который позволяет отображать внутрипрограммные уведомления. Я не буду заострять внимание на реализации, всех тонкостях работы с этим компонентом. Просто расскажу как пришла идея и основные возможности, а так же некоторые планы на будущее.

Идея создания

Все идеи как всегда идут из жизни, из каких-то конкретных потребностей и фантазий на тему того как можно было бы их реализовать. В данном случае идея пришла из приложения, которое мы разрабатывали в рабочее время. Приложение являлось толстым клиентом для расчета/перевода внутренней бухгалтерии во внешнюю, и многие операции совершались достаточно долго. Долго это значит от 2 минут до 30 и более. Конечно же на это время приложение не зависало, было вполне отзывчивым, но отзывчивым фактически только для одного действия, отмены долгоработающего метода. Всякие визуальные игры в виде сортировки по колонком не берем за серьезный функционал.

Архитектура приложения была построена так, что с долгой операцией (расчетами) связанной с базой данных был связан Id, который переписывался для каждого такого действия с базой, получается что в один момент можно было делать только одно большое действие и не переходить с экрана, для того, чтобы в конце концов узнать результат работы.

Очень хотелось сделать так, чтобы можно было достаточно безболезненно модифицировать имеющийся код, чтобы можно было осуществлять свободную навигацию по приложению и видеть отчет о завершенном действии в области уведомлений приложения. Отчего-то хотелось именно в самом приложении обо всем сообщать, а не выносить в «иконку рядом с часами». Не буду лукавить, это «отчего-то» пришло от частого созерцания области уведомлений на планшете с Android 4, и мне очень нравится то, как сделаны уведомления в системе и хотелось их как-то повторить.

Получается, что есть два желания, которые коррелируют друг с другом очень хорошо, по крайней мере лучше, чем идеи в фильме Super 8. А так как идеи достаточно давно вынашивались и могла появится конкретная польза, то я решил реализовать всё не отдавая себя прокрастинации.

Итак, основная идея:

Необходимо иметь возможность так проинстументализировать модели, чтобы они могли сообщить об окончании работ пользователю. Так же должна быть возможность перейти на экран, который сгенерировал сообщение.

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

Подробнее

Notification Bar Overview Video

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

Notification Bar Overview

WPF Exception Viewer

Сложность 100-200

Достаточно давно я писал о том, как работать (обрабатывать) с исключениями при использовании класса Task из Task Parallel Library (TPL), все описанные способы действительно работают и проверены на практике уже много раз и отлично меня спасают и упорядочивают работу с потоками, особенно с получением исключений. Однако тогда я упустил важный момент как еще централизованно можно получать исключения и никак не был освещен вопрос удобства работы с исключениями: отображение и коммуникация от пользователя. Сегодня собираюсь наверстать упущенное тем более под руку подвернулся удобный и простой набросок от MarkLTX с CodeProject.

Как оно бывает обычно

Обычно отчет об ошибке выглядит примерно следующим образом:

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

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

Так же пользователи не знаю, что текст можно копировать нажав Ctrl+C и высылают FullHD скриншот с ошибкой. Конечно весело порой посмотреть на чужие рабочие столы, но это быстро надоедает.

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

Подробнее

Make me async

Сложность 200

Почти месяц назад я написал статью «Эволюция сервисных методов». В ней я пришел к реализации библиотеки MakeMeAsync, которая позволяет декорировать вызовы методов, делая их асинхронными. При этом код остаётся максимально читабельным и чистым, на мой взгляд.

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

Кроме появления более четкой организации логики кода, значительно облегчилась задача по отображению ошибок, которые могли появиться во время выполнения задач в асинхронном режиме. Мне не надо было для каждой задачи прописывать/указывать метод обработки ошибки, можно было задать такой обработчик один раз в начале работы программы и все.

Итак, я думаю, что для начала стоит обновить информацию о том, как используется библиотека MakeMeAsync.

Подробнее

Эволюция сервисных методов

Сложность по шкале Microsoft 200-300

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

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

Простейшие

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

Не будем разводить дискуссий по поводу вырожденности примера, мол, большую часть времени есть аргументы и возвращаемое значение – суть от этого не поменяется. Сколько бы раз я не написал вызов этого метода, он будет выполнен последовательно, один за другим.

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

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

Подробнее

Создание nuspec файлов автоматически

В новой версии NuGet 1.3 можно создавать nuspec файлы автоматически. Ну или в полуавтоматическом режиме. Для этого можно будет сделать внешнюю команду в студии и использовать ее при необходимости создания пакетов NuGet. Сейчас я покажу как это делается, и что получается в итоге.

Для начала надо заполнить данные об авторе и компании в настройках проекта. Это можно сделать либо в ручную отредактировав файл AssemblyInfo.cs

 

Либо в настройках проекта на первой вкладке можно перейти на окошко Assembly Info и там заполнить необходимые поля.

Это важно, так как информация о пакете будет браться оттуда. Пока что концепция NuGet не может быть полностью отображена с помощью файла AssemblyInfo, так что файл nuspec нужен до сих пор. Ну да это не беда, уже не надо его писать руками полностью.

Файл спецификации nuspec создается с помощью команды spec. При этом рабочая директория должна быть та, где лежит файл проекта.

Таким образом настройка внешних инструментов будет выглядеть следующим образом.

После того, как завершите настройку nuget, как инструмента создания nuspec файлов, можно использовать его. Выбираем проект, который будет оформлен в виде Nuget пакета, Tools > Generate NuSpec и получаем нужный нам файл.

Подробнее

NuGet 1.3

Недавно вышла новая версия NuGet и я хотел бы освятить новые возможности, которые в нем появились. Сначала кратенько о том, что нового, потом подробнее рассмотрим изменения в привычных техниках работы.

Интеграция с symbol server

Теперь можно поставлять пакеты с файлами pdb для того, чтобы люди могли спокойно подебажиться в вашем проекте. Это может быть полезно, если вы разрабатываете общий продукт, а модули оформлены как nuget пакеты в локальном хранилище.

Новая команда Open-PackagePage

С помощью данной команды можно из командной строки менеджера пакетов переместиться на страницу пакета. Так же предоставляется возможность открыть и почитать лицензию, подать жалобу на пакет.

Общий синтаксис команды такой:

Open-PackagePage -Id <string> [-Version] [-Source] [-License] [-ReportAbuse] [-PassThru]

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

Далее

 

Подробнее

NuGet создание

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

Создание своего пакета NuGet

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

Для того, чтобы можно было библиотеку или набор библиотек включить в итоговый NuGet пакет,  необходимо добавить в проект файл с расширением “.nuspec”, где будут описаны все свойства и внутренние зависимости нашего пакета. Пока что в студии нет настроек для создание файлов требуемого расширения, так что можно создать любой текстовый файл, и сменить ему расширение.

В общем виде файл nuspec выглядит следующим образом:

 

Можно сказать, что комментарии тут излишни.  Единственное что стоит указать, какие тэги обязательны, а какие опциональные.

Подробнее