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

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

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

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

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

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

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

1 ответ

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

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

licensed under cc by-sa 3.0 with attribution.