Сообщение Re[4]: Как указать путь к dependency бибилотеке от 13.03.2023 16:15
Изменено 13.03.2023 16:19 Михаил Романов
Re[4]: Как указать путь к dependency бибилотеке
Здравствуйте, Barbar1an, Вы писали:
B>у меня чето не сработало, мож потому что у меня net6.0? там дето было написано что core игнорит подписи в ассемблях:
B>For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.
Сорри, я упустил момент, что речь может идти о .Net Core.
Да, там, похоже описанный вариант с <codeBase /> не работает.
Там, правда есть другой вариант, но он прямо скажем... нетривиальный.
В общем подробности можно посмотреть в статье Runtime Configuration Files
Для начала, нужно в файл [App].runtimeconfig.json добавить дополнительный путь поиска:
Далее идем в файл [App].deps.json и в разделе libraries и там находим нашу библиотеку. Будет что-то вроде
Если всё оставить как есть, то наша библиотека должна будет лежать по пути D:/Projects/AssemblyPath/ClassLibrary/bin/Debug/ClassLibrary/1.0.0
Если нас такое не устраивает, то можно добавить поле path, в котором указать или относительный (от значения в additionalProbingPaths) или абсолютный путь.
Т.е. сработают оба варианта:
и
Т.е. additionalProbingPaths указывает корень(и) путей поиска. А уже в path можно указывать любую подпапку ниже этого корня. Ну а по умолчанию (без path) это ./<Имя_библиотеки>/<версия>.
P.S. Не уверен, что разобрался во всех нюансах, но на первый взгляд вариант рабочий.
P.P.S. Оба файла создаются при компиляции и я с ходу не нашел, как задать в проекте нужные параметры для них. Т.е. если этот вариант подойдет, придется воротить какой-то пост-процессинг.
P.P.P.S. Если у вас self-hosted тип поставки, обязательно перепроверьте как работает на нем, потому что в документе, на который я сослался выше отдельно упоминалось, что для таких проектов файл необязателен (может он и обрабатывается иначе).
B>у меня чето не сработало, мож потому что у меня net6.0? там дето было написано что core игнорит подписи в ассемблях:
B>For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.
Сорри, я упустил момент, что речь может идти о .Net Core.
Да, там, похоже описанный вариант с <codeBase /> не работает.
Там, правда есть другой вариант, но он прямо скажем... нетривиальный.
В общем подробности можно посмотреть в статье Runtime Configuration Files
Для начала, нужно в файл [App].runtimeconfig.json добавить дополнительный путь поиска:
{
"runtimeOptions": {
"tfm": "net6.0",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "6.0.0"
},
"additionalProbingPaths": ["D:/Projects/AssemblyPath/ClassLibrary/bin/Debug"]
}
}
Далее идем в файл [App].deps.json и в разделе libraries и там находим нашу библиотеку. Будет что-то вроде
"ClassLibrary/1.0.0": {
"type": "project",
"serviceable": false,
"sha512": ""
}
Если всё оставить как есть, то наша библиотека должна будет лежать по пути D:/Projects/AssemblyPath/ClassLibrary/bin/Debug/ClassLibrary/1.0.0
Если нас такое не устраивает, то можно добавить поле path, в котором указать или относительный (от значения в additionalProbingPaths) или абсолютный путь.
Т.е. сработают оба варианта:
"ClassLibrary/1.0.0": {
"type": "project",
"serviceable": false,
"sha512": "",
"path": "D:/Projects/AssemblyPath/ClassLibrary/bin/Debug"
}
и
"ClassLibrary/1.0.0": {
"type": "project",
"serviceable": false,
"sha512": "",
"path": "."
}
Т.е. additionalProbingPaths указывает корень(и) путей поиска. А уже в path можно указывать любую подпапку ниже этого корня. Ну а по умолчанию (без path) это ./<Имя_библиотеки>/<версия>.
P.S. Не уверен, что разобрался во всех нюансах, но на первый взгляд вариант рабочий.
P.P.S. Оба файла создаются при компиляции и я с ходу не нашел, как задать в проекте нужные параметры для них. Т.е. если этот вариант подойдет, придется воротить какой-то пост-процессинг.
P.P.P.S. Если у вас self-hosted тип поставки, обязательно перепроверьте как работает на нем, потому что в документе, на который я сослался выше отдельно упоминалось, что для таких проектов файл необязателен (может он и обрабатывается иначе).
Re[4]: Как указать путь к dependency бибилотеке
Здравствуйте, Barbar1an, Вы писали:
B>у меня чето не сработало, мож потому что у меня net6.0? там дето было написано что core игнорит подписи в ассемблях:
B>For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.
Сорри, я упустил момент, что речь может идти о .Net Core.
Да, там, похоже описанный вариант с <codeBase /> не работает.
Там, правда есть другой вариант, но он прямо скажем... нетривиальный.
В общем подробности можно посмотреть в статье Runtime Configuration Files
Для начала, нужно в файл [App].runtimeconfig.json добавить дополнительный путь поиска:
Далее идем в файл [App].deps.json и в разделе libraries и там находим нашу библиотеку. Будет что-то вроде
Если всё оставить как есть, то наша библиотека должна будет лежать по пути D:/Projects/AssemblyPath/ClassLibrary/bin/Debug/ClassLibrary/1.0.0
Если нас такое не устраивает, то можно добавить поле path, в котором указать или относительный (от значения в additionalProbingPaths) или абсолютный путь.
Т.е. сработают оба варианта:
и
Т.е. additionalProbingPaths указывает корень(и) путей поиска. А уже в path можно указывать любую подпапку ниже этого корня. Ну а по умолчанию (без path) это ./<Имя_библиотеки>/<версия>.
P.S. Не уверен, что разобрался во всех нюансах, но на первый взгляд вариант рабочий.
P.P.S. Оба файла создаются при компиляции и я с ходу не нашел, как задать в проекте нужные параметры для них. Т.е. если этот вариант подойдет, придется воротить какой-то пост-процессинг.
P.P.P.S. Если у вас self-contained тип поставки, обязательно перепроверьте как работает на нем, потому что в документе, на который я сослался выше отдельно упоминалось, что для таких проектов файл необязателен (может он и обрабатывается иначе).
B>у меня чето не сработало, мож потому что у меня net6.0? там дето было написано что core игнорит подписи в ассемблях:
B>For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.
Сорри, я упустил момент, что речь может идти о .Net Core.
Да, там, похоже описанный вариант с <codeBase /> не работает.
Там, правда есть другой вариант, но он прямо скажем... нетривиальный.
В общем подробности можно посмотреть в статье Runtime Configuration Files
Для начала, нужно в файл [App].runtimeconfig.json добавить дополнительный путь поиска:
{
"runtimeOptions": {
"tfm": "net6.0",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "6.0.0"
},
"additionalProbingPaths": ["D:/Projects/AssemblyPath/ClassLibrary/bin/Debug"]
}
}
Далее идем в файл [App].deps.json и в разделе libraries и там находим нашу библиотеку. Будет что-то вроде
"ClassLibrary/1.0.0": {
"type": "project",
"serviceable": false,
"sha512": ""
}
Если всё оставить как есть, то наша библиотека должна будет лежать по пути D:/Projects/AssemblyPath/ClassLibrary/bin/Debug/ClassLibrary/1.0.0
Если нас такое не устраивает, то можно добавить поле path, в котором указать или относительный (от значения в additionalProbingPaths) или абсолютный путь.
Т.е. сработают оба варианта:
"ClassLibrary/1.0.0": {
"type": "project",
"serviceable": false,
"sha512": "",
"path": "D:/Projects/AssemblyPath/ClassLibrary/bin/Debug"
}
и
"ClassLibrary/1.0.0": {
"type": "project",
"serviceable": false,
"sha512": "",
"path": "."
}
Т.е. additionalProbingPaths указывает корень(и) путей поиска. А уже в path можно указывать любую подпапку ниже этого корня. Ну а по умолчанию (без path) это ./<Имя_библиотеки>/<версия>.
P.S. Не уверен, что разобрался во всех нюансах, но на первый взгляд вариант рабочий.
P.P.S. Оба файла создаются при компиляции и я с ходу не нашел, как задать в проекте нужные параметры для них. Т.е. если этот вариант подойдет, придется воротить какой-то пост-процессинг.
P.P.P.S. Если у вас self-contained тип поставки, обязательно перепроверьте как работает на нем, потому что в документе, на который я сослался выше отдельно упоминалось, что для таких проектов файл необязателен (может он и обрабатывается иначе).