Рубрика: C#

В механизме событий .NET отсутствует стандартная возможность избежать повторной подписки на сообщения. То есть, при повторной подписке на один и тот же обработчик будет вызываться столько раз, сколько раз была произведена подписка на событие. Но можно реализовать такую функциональность в программе самостоятельно одним из двух способов. Первый способ — удалять обработчик через оператор -= при добавлении нового подписчика и тут же его добавлять:

public class NonDuplicateEventArgs : EventArgs
    {
      public NonDuplicateEventArgs(string message)
      {
        Message = message;
      }

      public string Message { get; set; }
    }

    protected event EventHandler<nonDuplicateEventArgs> _nonDuplicateEvent;

    /// <summary>
    /// Событие с проверкой на добавление обработчиков-дубликатов путем удаления и добавления обработчика заново
    /// </summary>
    public event EventHandler<nonDuplicateEventArgs> NonDuplicateEvent
    {
      add
      {
        // пытаемся удалить обработчик, затем добавляем снова
        _nonDuplicateEvent -= value;
        _nonDuplicateEvent += value;
      }
      remove { _nonDuplicateEvent -= value; }
    }

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

using System.Linq;

 private EventHandler<nonDuplicateEventArgs> _nonDuplicateEventInvocList;

    /// <summary>
    /// Событие с проверкой  на добавление  обработчиков-дубликатов через GetInvocationList
    /// </summary>
    public event EventHandler<nonDuplicateEventArgs> NonDuplicateEventInvocList
    {
      add
      {
        if (_nonDuplicateEventInvocList == null ||
            !_nonDuplicateEventInvocList.GetInvocationList().Contains(value))
        {
          _nonDuplicateEventInvocList += value;
        }
      }
      remove { _nonDuplicateEventInvocList -= value; }
    }

Для того, чтобы решить, что же выбрать в своем приложении, я сделал небольшой тест. Как и ожидалось, метод с GetInvocationList для проверки одного и того же обработчика работает существенно медленнее, чем удаление и добавление — более чем в 5 раз медленнее (11.7 секунд против 2.2)

Action measureTime = (action, actionCaption) =>
{
var time = DateTime.Now;
action();
TimeSpan span = DateTime.Now — time;
Console.WriteLine(«{0} time: {1:0.000}», actionCaption,span.TotalSeconds);
};

int testCount = 10000000;

//замеряем скорость добавления одного и того же подписчика на событие
SmartEvents smartEvents = new SmartEvents();
measureTime(() =>
{

for (int i = 0; i < testCount; i++) { smartEvents.NonDuplicateEvent += OnNonDuplicateEvent; } }, "NonDuplicate"); measureTime(() =>
{

for (int i = 0; i < testCount; i++) { smartEvents.NonDuplicateEventInvocList += OnNonDuplicateEvent; } }, "NonDuplicateEvent with InvocationList"); [/sourcecode]

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

//замеряем скорость добавления нескольких подписчиков в случайном порядке

var methods = new EventHandler[]
{
OnNonDuplicateEvent, OnNonDuplicateEvent2,
OnNonDuplicateEvent3, OnNonDuplicateEvent4,
OnNonDuplicateEvent5, OnNonDuplicateEvent6
};
testCount /= methods.Length;//чтобы долго не ждать

Random r = new Random(0);

var list = Enumerable.Range(0, testCount).Select(z => methods[r.Next(methods.Length)]).ToArray();

measureTime(() =>
{

for (int i = 0; i < testCount; i++) { smartEvents.NonDuplicateEvent += list[i]; } }, "NonDuplicate for" + methods.Length + "subscribers"); measureTime(() =>
{

for (int i = 0; i < testCount; i++) { smartEvents.NonDuplicateEventInvocList += list[i]; } }, "NonDuplicateEvent with InvocationList" + methods.Length + "subscribers"); } [/sourcecode] Полный код решения с тестами можно скачать по ссылке.

Компания Redgate представила первую часть книги, посвященной проблемам менеджемента памяти. Первая часть книги «Under the Hood of .NET Memory Management» доступна для скачивания.

В этой статье рассматривается два наиболее простых способа реализации автообновления приложения .Net. Первый способ — с помощью стандартной технологии Microsoft — Click Once, второй — с помощью опенсорного компонента NET Application Updater Component.

Обновление с помощью ClickOnce

Процесс использования ClickOnce описан в этой статье. Однако, установка с помощью этой технология делает неправильный мед» не позволяет установить программу для всех пользователей, поэтому переходим к следующему пункту.

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

Обновление с помощью NET Application Updater Component

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

1. Создаем новый проект Windows Forms, например с именем MySimpleSample

2. Добавляем проекты AppStart и AppUpdater. Добавляем Reference на на проект AppUpdater. В AppUpdater есть ссылка на класс AppStartConfig, лежащий в проекте AppStart, поэтому проекты AppStart и AppUpdater лучше положить на одном уровне файловой структуры.

3. Добавляем на форму компонент AppUpdater ( Со окна Toolbox-AppUpdater Components). Тут были некоторые проблемы, скорее всего это связано с обновлением проекта до Visual Studio 2010 . UpdateLog хочет писать в файл AppUpdate.log, но текущим каталогом, возвращаемым функцией GetLogFilePath является путь к Visual Studio, куда, естественно запись запрещена. Можно поправить выбор каталога на что-нибудь такое :

DirectoryInfo DI = new DirectoryInfo(Assembly.GetCallingAssembly().Location);

В классе AppDownloader нас будет ожидать еще один сюрприз — захардкоженное имя конфига «AppStart.config». Явная недоделка — исправляем хотя бы на константу для централизации.

Читать далее Автообновление приложений .NET

Мой перевод статьи «When Should I Use Parallel.ForEach? When Should I Use PLINQ?», опубликованный ранее на Хабрахабре.

Введение

Обычно, при оптимизации программы для многоядерных компьютеров первым шагом является выяснение возможности разделения алгоритма на части, выполняющиеся параллельно. Если для решения задачи необходимо параллельно обрабатывать отдельные элементы из большого набора данных, то первыми кандидатами станут новые возможности параллельности в .NET Framework 4: Parallel.ForEach и Parallel LINQ (PLINQ)

Parallel.ForEach

Класс Parallel содержит метод ForEach, представляющий собой многопоточную версию обычного цикла foreach в C#. Подобно обычному foreach, Parallel.ForEach выполняет итерации над перечислимыми данными (enumerable), но с использованием множества потоков. Одна из более часто используемых перегрузок Parallel.ForEach выглядит следующим образом:

public static ParallelLoopResult ForEach<tsource>(
			 IEnumerable</tsource><tsource> source,
			 Action</tsource><tsource> body)

Ienumerable указывает на последовательность, по которой нужно выполнить итерации, а Action body задает делегат, вызываемый для каждого элемента. Полный список перегрузок Parallel.ForEach можно найти здесь.

PLINQ

Родственный с Parallel.ForEach PLINQ представляет собой модель программирования для паралелльных операций над данными. Пользователь определяет операцию из стандартного набора операторов, включающих в себя проекции, фильтры, агрегирование и т.д. Подобно Parallel.ForEach PLINQ достигает параллельности, разбивая входную последовательность на части и обрабатывая элементы в разных потоках.

В статье выделяются различия между этими двумя подходами к параллельности. Разбираются сценарии использования, в которых лучше всего использовать Parallel.ForEach вместо PLINQ и наоборот.

Выполнение независимых операций

Читать далее Когда использовать Parallel.ForEach, а когда PLINQ