FxCop, составить список абонентов из зависимой сборки

Question

Я создаю пару таможенных правил FxCop, и одно из правил должно обеспечивать, чтобы конструктор вызывался в определенных методах. Для этого мне нужно создать список вызывающих, для этого конкретного конструктора, перед выполнением фактического теста. Как это возможно? Есть ли какой-то дескриптор для получения списка всех загруженных сборок в ApplicationDomain, где я могу перебирать классы и находить объект-метод конструктора? В идеале список абонентов должен быть составлен в методе BeforeAnalysis.

Answer 1

Я думаю, что не очень хорошо объяснил вопрос, но я понимаю вашу точку зрения.У меня есть 3 разные сборки, и для определенных вызовов методов из одной сборки в другую необходимо убедиться, что вызывается конструктор эталонных тестов.Класс теста находится в 4-й сборке.Теперь моя проблема заключалась в том, что только VS2010 загружает только одну целевую сборку для анализа, и когда я использовал CallGraph для создания списка методов, вызывающих constructur, он не нашел ни одного.При ручном вызове FxCopCmd.exe я мог просто вручную добавить зависимые сборки с параметром / file :.

Мое решение состоит в том, чтобы загрузить различные сборки вручную (не полагаясь на загруженную сборку в RuleUtilities.AnalysisAssemblies и составить список вызывающих в методе BeforeAnalysis.

            RuleUtilities.GetAssembly(
            RuleUtilities.AnalysisAssemblies
            .First().Directory + "\\" + additionalAssemblyFilename)
            .Types.SelectMany(type => type.Members)
            .Where(member => member.IsPublic)
            .Where(CanBeCastedToMethod)
            .Cast<Method>()
            .SelectMany(CallGraph.CallersFor);

При таком подходеможет составить список абонентов для каждой сборки и для конструктора класса производительности. Отлично работает в VS2010.

Answer 2

Метод Microsoft.FxCop.Sdk.CallGraph.CallersFor (Method) может дать вам то, что вы хотите.Тем не менее, общий подход, который вы, кажется, описываете, редко бывает хорошей идеей, потому что он обычно назначает проблемы неправильной цели.Например, в описываемом вами сценарии, вероятно, было бы желательно отнести проблемы к методам, которые должны, но не содержат целевой вызов конструктора.Однако если целью анализа является конструктор, обнаруженные проблемы будут относиться к конструктору, а не к методам, которые должны были его вызвать.