Опыт кастомного анализа c# кода

Спасибо за совет.
Неужели опять, как в молодсти, придется «ассемблером» развлекаться :).

Опыт кастомного анализа c# кода

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

Опыт кастомного анализа c# кода

Может сам mezastel может так сразу ответить на этот вопрос.
А еще нет, но попробую посмотреть.

Опыт кастомного анализа c# кода

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

Опыт кастомного анализа c# кода

2. Вам не сильно важна производительность
Метод GetCurrentClassLogger использует обращение к текущему стэку вызовов, что является небыстрой операцией.
github.com/NLog/NLog/blob/master/src/NLog/LogManager.cs#L161

Но разве плохая производительность не подталкивает к использованию именно «статической» переменной, которая создается одна на тип (класс), а не на каждый объект?

Опыт кастомного анализа c# кода

Интересно, почему ребята из nlog советуют:

In most cases you will have one logger per class, so it makes sense to give logger the same name as the current class. LogManager exposes a method which creates a logger for current class, called GetCurrentClassLogger(). Because loggers are thread-safe, you can simply create the logger once and store it in a static variable:

namespace MyNamespace
{
  public class MyClass
  {
    private static Logger logger = LogManager.GetCurrentClassLogger();
  }
}

или это, что бы nlog было сложнее выпилить? :)

Опыт кастомного анализа c# кода

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

Согласен, но у меня есть пример, когда DI еще нет, а лог уже есть.

Опыт кастомного анализа c# кода

а его про себя называю «решарпо-дебаггер» :)

Опыт кастомного анализа c# кода

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

и конечно, спасибо, за наводку.

Опыт кастомного анализа c# кода

Я сам написал эту статью по мотивам ответов на несколько другие проблемы :). Так что и за это мы хабр любим.

Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

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

Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

А если речь идет не о модульных тестах?
Модульный тест проверят, что мой код вызвал удаление файла.
Интеграционный тест должен проверять, что файл действительно был удален.

Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

Не обнаружил никаких изменений в работе теста после добавления KeepAlive.

Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

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

Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

Как то не задавался этим вопросом. Думаю, что в общем случае не часто. По крайней мере профайлинг давно не указывал на работу с файлами.

Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

CA1063 хорошая вещь, но в данном случае слишком сильная: я бы начал с финализатора, а правило CA1063 проверяет и Dispose() тоже.
Кстати, а какие есть способы добавить свою статическую проверку (правило)? Microsoft Code Analysis вроде бы не позволяет. Может есть плагин для R#? Или можно самому такой реализовать. У меня есть желание анализировать наши кастомные штуки, но вот пока не знаю как (приходится простым поиском и глазками).

Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

Т.е. надо и производительность проверить и сравнить с GUID реализацией?
Или эту работу уже кто-нибудь сделал?

Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

Вам не нужно тестировать File.Delete. Это уже не ваша забота. Что стоит протестировать — это факт того, что File.Delete вызывается. Для этого в Visual Studio есть Fake Assemblies.

Что бы использовать Fake Assemblies, мне нужно иметь тестовый проект от Microsoft или достаточно обычного проекта с nunit тестами?

Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

Прикольная реализация :)

 void Delete(string fileName) {
            try {
                File.Delete(fileName);
            }
            catch {
                // Ignore all exceptions
            }
        }

Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

ок. Это действительно может поменять все дело. Буду проверять.
Спасибо.