Комментарии 10
В Full .Net можно на событии резолва сборки ссылаться на подпапку и например вынести все сборки в подпапку lib.
Можно ли это сделать для .Net Core или какие то либы ищутся строго по указанным путям и выбора нет?
Можно ли это сделать для .Net Core или какие то либы ищутся строго по указанным путям и выбора нет?
Можно. Вот пример кода из живого проекта с #if-ами на .NET Core и Full .NET
Вероятно вы имеете ввиду это?
Используя --additional-deps и --additionalprobepaths мы можем размещать runtime-компоненты в нужной нам файловой структуре.
Оно дает прямо возможность все либы убрать из корня или не все? Вот это по статье мне непонятно.
Для Standalone полностью убрать все файлы из корня не получится:
— библиотека hostfxr.dll должна находится строго в \host\fxr\[x.y.z]\ (FDD) или папке с приложением (SCD);
— для SCD файл приложения MyApp.dll и deps-файл должны быть в одной папке с запускаемым файлом MyApp.exe. И тут интересный момент, сами файлы могут находится в другом месте и быть переопределены аргументами additional-deps и additionalprobingpath, но в корне могут быть пустые файлы с такими же названиями, поскольку наличие/отсутствие этих файлов по соглашению определяют тип выполнения
— библиотека hostfxr.dll должна находится строго в \host\fxr\[x.y.z]\ (FDD) или папке с приложением (SCD);
— для SCD файл приложения MyApp.dll и deps-файл должны быть в одной папке с запускаемым файлом MyApp.exe. И тут интересный момент, сами файлы могут находится в другом месте и быть переопределены аргументами additional-deps и additionalprobingpath, но в корне могут быть пустые файлы с такими же названиями, поскольку наличие/отсутствие этих файлов по соглашению определяют тип выполнения
Здесь пример того, как в SCD можно вынести в подпапку lib все, что можно. На что следует обратить внимание:
— путь к подпапке указан в runtimeconfig
— поскольку в additional probing paths поиск зависимостей происходит по относительному пути (path пакета из секции libraries + относительный путь из секции dependencies), то deps-файл пришлось «подправить», убрав лишние части.
— hostpolicy.dll должна быть в т.н. package layout, т.е. ее нельзя положить в корень lib
— пути coreclr.dll и corejit.dll должны начинаться с символа '/'
— путь к подпапке указан в runtimeconfig
— поскольку в additional probing paths поиск зависимостей происходит по относительному пути (path пакета из секции libraries + относительный путь из секции dependencies), то deps-файл пришлось «подправить», убрав лишние части.
— hostpolicy.dll должна быть в т.н. package layout, т.е. ее нельзя положить в корень lib
— пути coreclr.dll и corejit.dll должны начинаться с символа '/'
В .NET Core 2.0 также можно использовать событие AppDomain.AssemblyResolve.
Однако оно вызывается уже после запуска Core CLR, если не удалось найти сборку в probe paths.
Суть использования deps-файла — проверить до запуска CLR, что все управляемые зависимости на месте и передать их в виде списка (TPA), чтобы AppDomain тратил меньше времени на поиск.
Однако оно вызывается уже после запуска Core CLR, если не удалось найти сборку в probe paths.
Суть использования deps-файла — проверить до запуска CLR, что все управляемые зависимости на месте и передать их в виде списка (TPA), чтобы AppDomain тратил меньше времени на поиск.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Структура и модель выполнения .NET Core приложений