Есть какое-то приложение ввиде exe которое референсится на какую-то библиотеку
При этом наша библиотека не лежит в папке приложения ни в корне ни в субдиреатории
А лежит гдето в совсем другом месте

К запустить такое приложение?

У нативных dll я могу установить PATH, но дотнет не уважает его

Здравствуйте, Barbar1an, Вы писали:

B>Есть какое-то приложение ввиде exe которое референсится на какую-то библиотеку
B>При этом наша библиотека не лежит в папке приложения ни в корне ни в субдиреатории
B>А лежит гдето в совсем другом месте

Засунь эту либу в GAC.

Здравствуйте, Baiker, Вы писали:

B>Здравствуйте, Barbar1an, Вы писали:

B>>Есть какое-то приложение ввиде exe которое референсится на какую-то библиотеку
B>>При этом наша библиотека не лежит в папке приложения ни в корне ни в субдиреатории
B>>А лежит гдето в совсем другом месте

B>Засунь эту либу в GAC.

написано что на проде так делать низя а только лишь в девелоперских целях

B>У нативных dll я могу установить PATH, но дотнет не уважает его

Лучше всего копию этой библиотеки в папку приложения положить (инсталлятором приложения).
Или зарегистрировать в GAC (тоже инсталлятором), но тогда нужно делать strong name у этой библиотеки.

Если оба варианта не подходят, то повесить в приложении обработчик AssemblyResolve и подсовывать библиотеку подгруженную по Assembly.Load из другого места.
(см. например https://rsdn.org/forum/dotnet/2433522

Автор: altarvic
Дата: 05.04.07

)

B>Есть какое-то приложение ввиде exe которое референсится на какую-то библиотеку
B>При этом наша библиотека не лежит в папке приложения ни в корне ни в субдиреатории
B>А лежит гдето в совсем другом месте

Через конфиг можно попробовать.

https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/codebase-element

If the assembly has a strong name, the codebase setting can be anywhere on the local intranet or the Internet. If the assembly is a private assembly, the codebase setting must be a path relative to the application's directory.

Здравствуйте, yenik, Вы писали:

B>>Есть какое-то приложение ввиде exe которое референсится на какую-то библиотеку
B>>При этом наша библиотека не лежит в папке приложения ни в корне ни в субдиреатории
B>>А лежит гдето в совсем другом месте

Y>Через конфиг можно попробовать.

Y>https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/codebase-element
Y>

Y>If the assembly has a strong name, the codebase setting can be anywhere on the local intranet or the Internet. If the assembly is a private assembly, the codebase setting must be a path relative to the application's directory.

чето не работает, пути пробовал разные, и формате винды, и как урл , и полные и относительные


DemoApplication.exe.config

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
            <assemblyIdentity name="DemoLibraryA"
                              />
            <codeBase version="0.0.55.0"
                      href="../../uo-demolibrarya-dotnet/0.0.55.0/DemoLibraryA.dll"/>
         </dependentAssembly>
         <dependentAssembly>
            <assemblyIdentity name="DemoLibraryAA"
                              />
            <codeBase version="0.0.55.0"
                      href="../../uo-demolibraryaa-dotnet/0.0.55.0/DemoLibraryAA.dll"/>
         </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

Здравствуйте, Barbar1an, Вы писали:

B>Есть какое-то приложение ввиде exe которое референсится на какую-то библиотеку
B>При этом наша библиотека не лежит в папке приложения ни в корне ни в субдиреатории
B>А лежит гдето в совсем другом месте

Лучше положить в каталог с ехе.

B>К запустить такое приложение?

Как вариант сделать свой резолв сборок.

Или как предлагается рямом в GAC засунуть. За одно грузиться будет быстрее.

Здравствуйте, Barbar1an, Вы писали:

B>чето не работает, пути пробовал разные, и формате винды, и как урл , и полные и относительные
У меня сработало, но только при условии:
— сборка, на которую ссылаемся, имеет строгое имя (подписана)
— в файле настроек указаны абсолютные пути в виде URN
— указаны все компоненты имени сборки: токен, культура, версия

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="ClassLibrary" publicKeyToken="c9c4cfe1f3ad3405" culture="neutral" />
                <codeBase version="1.0.0.0" href="file:///D:/Projects/AssemblyPath/ClassLibrary/bin/Debug/ClassLibrary.dll "/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.8" />
    </startup>
</configuration>

Здравствуйте, Barbar1an, Вы писали:

B>Есть какое-то приложение ввиде exe которое референсится на какую-то библиотеку
B>При этом наша библиотека не лежит в папке приложения ни в корне ни в субдиреатории
B>А лежит гдето в совсем другом месте

B>К запустить такое приложение?

B>У нативных dll я могу установить PATH, но дотнет не уважает его

probing если библиотека будет в подкаталоге. необязательно подписывать.
или загрузка через Reslove

Здравствуйте, Михаил Романов, Вы писали:

МР>У меня сработало, но только при условии:
А вот коллега vaa

Автор: vaa
Дата: 12.03.23

дал хорошую ссылку, где мои наблюдения подтверждаются:

Referenced assemblies outside the application's root directory must have strong names and must either be installed in the global assembly cache or specified using the <codeBase> element.

Т.е. у сборки за пределами корня приложения (и не важно указан прямой путь или мы берем из GAC) действительно должно быть строгое имя и ссылаться на неё нужно именно по строгому имени.

Здравствуйте, Barbar1an, Вы писали:

B>Здравствуйте, yenik, Вы писали:

B>>>Есть какое-то приложение ввиде exe которое референсится на какую-то библиотеку
B>>>При этом наша библиотека не лежит в папке приложения ни в корне ни в субдиреатории
B>>>А лежит гдето в совсем другом месте

Y>>Через конфиг можно попробовать.

Y>>https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/codebase-element
Y>>

Y>>If the assembly has a strong name, the codebase setting can be anywhere on the local intranet or the Internet. If the assembly is a private assembly, the codebase setting must be a path relative to the application's directory.

у меня чето не сработало, мож потому что у меня net6.0? там дето было написано что core игнорит подписи в ассемблях:

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.

Здравствуйте, 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 добавить дополнительный путь поиска:

{
  "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 тип поставки, обязательно перепроверьте как работает на нем, потому что в документе, на который я сослался выше отдельно упоминалось, что для таких проектов файл необязателен (может он и обрабатывается иначе).

Здравствуйте, Михаил Романов, Вы писали:

МР>Здравствуйте, 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 добавить дополнительный путь поиска:

чтото у меня и это не сработало

Здравствуйте, Михаил Романов, Вы писали:

вообще там написано, что path имеет смысл тока в пакетах

path — in the package library this is a relative path where to find the assets.

GAC- я бы не рассматривал вообще.

The global assembly cache (GAC) does not exist as a concept in .NET Core and .NET 5 and later versions.

https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/global-assembly-cache-apis-obsolete

Здравствуйте, Barbar1an, Вы писали:

B>чтото у меня и это не сработало
Вот мой солюшен http://files.rsdn.org/29231/AssemblyPath.zip
Я там попробовал указать даже относительные пути — работает.

Попробуйте скачать и собрать (хоть в Release, хоть в Debug) и потом:
1. Убедиться, что в бинарники к ConsoleApp не попала ClassLibrary.dll
2. К бинарникам от ConsoleApp подложить ConsoleApp.deps.json и ConsoleApp.runtimeconfig.json из корня архива (там сразу прописано искать и в Debug и в Release)
3. Запустить ConsoleApp.exe

Здравствуйте, Barbar1an, Вы писали:

B>вообще там написано, что path имеет смысл тока в пакетах

Да, но по факту в приложенном примере у меня оно завелось.

Здравствуйте, Михаил Романов, Вы писали:

МР>Здравствуйте, Barbar1an, Вы писали:

B>>вообще там написано, что path имеет смысл тока в пакетах

МР>Да, но по факту в приложенном примере у меня оно завелось.

у меня в итоге тоже заработало, оказалось, что вот это —
"path" : "."
— обязательно нада добавить

пасиба)