Комментарии 10
В Full .Net можно на событии резолва сборки ссылаться на подпапку и например вынести все сборки в подпапку lib.
Можно ли это сделать для .Net Core или какие то либы ищутся строго по указанным путям и выбора нет?
Можно ли это сделать для .Net Core или какие то либы ищутся строго по указанным путям и выбора нет?
0
Можно. Вот пример кода из живого проекта с #if-ами на .NET Core и Full .NET
+1
Вероятно вы имеете ввиду это?
Используя --additional-deps и --additionalprobepaths мы можем размещать runtime-компоненты в нужной нам файловой структуре.
0
Оно дает прямо возможность все либы убрать из корня или не все? Вот это по статье мне непонятно.
0
Для 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, но в корне могут быть пустые файлы с такими же названиями, поскольку наличие/отсутствие этих файлов по соглашению определяют тип выполнения
0
Здесь пример того, как в 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 должны начинаться с символа '/'
0
В .NET Core 2.0 также можно использовать событие AppDomain.AssemblyResolve.
Однако оно вызывается уже после запуска Core CLR, если не удалось найти сборку в probe paths.
Суть использования deps-файла — проверить до запуска CLR, что все управляемые зависимости на месте и передать их в виде списка (TPA), чтобы AppDomain тратил меньше времени на поиск.
Однако оно вызывается уже после запуска Core CLR, если не удалось найти сборку в probe paths.
Суть использования deps-файла — проверить до запуска CLR, что все управляемые зависимости на месте и передать их в виде списка (TPA), чтобы AppDomain тратил меньше времени на поиск.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Структура и модель выполнения .NET Core приложений