Должен ли я рассматривать объекты из "немой" управляемой обертки над родной COM-dll как неуправляемые ресурсы?

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

  • Управляемая оболочка по существу автоматически генерируется скриптом, учитывая объявления типа COM в качестве входных данных.
  • СОМ-уровень будет внутренне получать доступ к сети, файловой системе, графике и другим неуправляемым ресурсам.
  • Большинство управляемых типов в оболочке создаются с использованием заводских методов.
  • Большинство управляемых типов в оболочке не имеют возможности вручную запускать очистку или освобождение ресурсов.
  • Управляемый тип в обертке не реализует IDisposable.
  • Никакой управляемый тип в оболочке явно не реализует финализатор.

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

Вопрос в том, насколько я прав в своем понимании этого:

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

Правильно ли я в этом?

1 ответ

Нет, это не совсем правильно. Когда сборщик мусора собирает управляемые типы, ссылающиеся на типы COM, эти ссылки будут разыменовываться с помощью вызова COM Release. В этой точке неуправляемые ресурсы будут выпущены, если ничего другого не будет ссылка на экземпляр COM-объекта.

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

licensed under cc by-sa 3.0 with attribution.