Убедитесь, что возвращаемое значение метода не выбрано для библиотеки

Question

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

Такое значение может быть сохранено или использовано в качестве аргумента для другого метода. Это не строго использовать сохраненное значение, но если оно просто отбрасывается, это 100% ошибка.

Есть ли какой-либо простой способ настроить это для моих пользователей библиотеки?

var x = instance.Method(); // ok 
field = instance.Method(); // ok 
instance.OtherMethod(instance.Method()); // ok 
MyMethod(instance.Method()); // ok, no need to check inside MyMethod 
instance.Method(); // callvirt and pop - error! 

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

Answer 1

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

Использование везде, как предлагается в комментариях, затрудняет использование библиотеки.

Поэтому я выбрал другой подход.

1. В финализаторе я проверяю, был ли вызван какой-либо метод (этого достаточно для подтверждения использования). Если нет - InvalidOperationException. Создание объекта StackTrace может быть записано и добавлено в сообщение об ошибке.
2. Пользователь может вызвать SetNotLeaked(), чтобы отключить проверку для конкретного объекта и всех внутренних объектов рекурсивно.

Это не проверка времени компиляции, но это, безусловно, будет замечено.

Это не очень изящное решение, и оно нарушает некоторые рекомендации, но оно делает то, что мне нужно, не позволяет пользователю просматривать лишние предупреждения (решение RuleSet) и не влияет на чистоту кода (вне).

Для тестов я должен был сделать базовый класс, где я могу настроить Appdomain.UnhandledException обработчик в SetUp метода и проверки (после GC.Collect) было ли какое-либо исключение, брошенной в TearDown, потому что финализации вызывается из другого потока и NUnit иначе показывает испытание, как прошло.

Answer 2

Если вы реализуете Code Analysis/FXCop, правило CA1806 - Не игнорируйте метод приводит бы обложка этот случай.

См: How to Enable/Disable Code Analysis for Managed Code

В принципе, это так же просто, как собирается в файл проекта, вкладки анализа кода, установив флажок и выбрать, какие правила ошибки/предупреждают о.

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

Вот набор правил с правилом я имею в виду:.