#c# #.net #dependencies #clr #pinvoke
#c# #.net #зависимости #clr #pinvoke
Вопрос:
У меня есть приложение .net (4.7.2), которое вызывает стороннюю собственную библиотеку с помощью [DllImport("Foo.dll"...)] . Этот собственный язык Foo.dll написан на C и имеет множество зависимостей: в настоящее время поставляется 90 сборок, 360 МБ (!). Я знаю, что некоторые зависимости поставляются, но больше не используются. Запрос этой третьей стороны на очистку не имел никакого эффекта, его становится все больше и больше каждые несколько месяцев.
Вопрос: Есть ли какой-либо способ отличить требуемые, активно загружаемые собственные сборки от раздувания dll?
Я экспериментировал с AppDomain.GetAssemblies() выходом из приложения, но он возвращает только управляемые сборки. Я экспериментировал с DependencyWalker и его современными зависимостями, но, похоже, большинство действительно необходимых зависимостей Foo.dll загружаются по требованию — в этих приложениях отображается лишь небольшая часть.
Комментарии:
1. Возможно, ProcessExplorer был бы полезен? Он должен иметь возможность отображать все библиотеки DLL, загруженные процессом.
2. Process Explorer не является хорошим вариантом. Поскольку DLL по определению загружаются динамически, вы рискуете столкнуться с пограничным случаем во время выполнения, что приведет к отсутствию библиотеки.
Ответ №1:
Вы могли бы использовать Procmon для отслеживания динамически загружаемых сборок.
Но если некоторые сборки загружаются только в том случае, если функция используется, то у вас нет другого выбора, кроме как просмотреть код (если вы можете) или просмотреть все возможные пути к коду и отслеживать все загруженные библиотеки DLL.