2013-03-03 5 views
0

Я тестирую комплексное .net/COM-приложение в Intel Inspector (утечки собственной памяти). В довольно многих местах в .net-коде мы кэшируем ссылки на COM-объекты в статических полях. Очевидно, Инспектор отмечает, что они являются утечками. В некоторых случаях достаточно подавления подавления, однако иногда количество объектов, помеченных (созданных как часть основного COM-объекта), выходит из-под контроля (сотни), и подавление может скрыть похожие шаблоны, которые являются фактическими утечками. Сделать длинную историю коротким - как раз перед выходами процесса Я повторяю все классы во всех сборках, загружаемых в appdomain, и я устанавливаю нулевые статические поля, ссылающиеся на мои COM-объекты. Это было бы здорово для будущего использования, если бы я мог печатать все статические поля, ссылающиеся на COM-объекты, даже если они еще не были приняты как допустимые кеши (и могут быть фактическими утечками).Как определить, был ли статический конструктор выполнен в .net?

Однако, если тип никогда не использовался, его статический конструктор будет выполняться, когда я вызываю getField (чтобы увидеть, является ли он нулевым) и может создавать больше COM-объектов. Есть ли способ определить, когда тип использовался в текущем AppDomain?

ответ

0

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

public static class ClassRegistrar 
{ 
    private static List<Type> registered = new List<Type>(); 
    public static void Register(Type type) 
    { 
     registered.Add(type); 
    } 
    public static IEnumerable<Type> Registered 
    { get { return registered; } } 
} 

public class MyClass 
{ 
    static MyClass() 
    { 
     ClassRegistrar.Register(typeof(MyClass)); 
    } 
} 
+0

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

+0

Ну, короткий ответ заключается в том, что вы не можете делать то, что хотите. Если вы предоставите некоторый пример кода (даже в F #), я уверен, что он либо выявит недостаток архитектуры, либо способ обойти его. –

+0

Филипп, я думаю, что мой первый пункт говорит все - это просто тест, и он не оправдывает изменение 1000+ проектов, чтобы зарегистрировать экземпляр класса. Если дело доходит до худшего, мне нужно будет просто обработать мой код на основе исследований ручной отладки (когда Inspector флага утечки отслеживает, какой класс содержит ссылку на него). – MichalMa

Смежные вопросы