Проект deps.json не заполняется при использовании ссылки на проект, хотя он содержит встроенный пакет NuGet.

Проект deps.json не заполняется при использовании ссылки на проект, хотя он содержит встроенный пакет NuGet. ⇐ Linux

1 сообщение • Страница 1 из 1

Anonymous

Проект deps.json не заполняется при использовании ссылки на проект, хотя он содержит встроенный пакет NuGet.

Цитата

Сообщение Anonymous » 30 мар 2026, 17:56

У меня есть решение, содержащее проект библиотеки классов. Этот проект библиотеки классов включает в себя собственную библиотеку, которую я помещаю в подкаталог runtimes//native. У меня есть .csproj, настроенный для упаковки файлов библиотеки в папку среды выполнения внутри файла .nupkg, и когда я создаю
для этого построенного пакета, deps.json потребляющего проекта обновляется, чтобы найти собственную библиотеку в папке каждого RID.
Но если я сделаю ссылку проекта на библиотеку классов в том же решении, этот проект deps.json не заполняется необходимой информацией.
Итак, код, который ссылается на эту библиотеку классов как на пакет NuGet, работает, но если этот
заменить на , тот же код не запустится, поскольку он не знает, где найти собственный файл библиотеки.
Есть ли способ настроить библиотеку классов .csproj чтобы ссылки на проекты в одном решении получали ту же правильную конфигурацию deps.json, что и проекты, которые ссылаются на него через пакет NuGet?
ETA: чтобы увидеть это в действии, клонируйте эти два проекта:
https://github.com/logiclrd/QBX
https://github.com/logiclrd/DQD.ForkPTY
Вы должен иметь возможность компилировать и запускать QBX на Linux x64. (Целью DQD.ForkPTY является поддержка нескольких платформ, но опубликованная в настоящее время версия находится на ранней стадии и на данный момент поддерживает только linux-x64.)
QBX включает DQD.ForkPTY в качестве
. В результатах сборки вы должны увидеть дерево папок среды выполнения, включающее файл libDQD.ForkPTY.Native.Linux.so и файл deps.json, который направляет запуск linux-x64 к этому файлу.
Теперь откройте решение DQD.ForkPTY. В нем есть два проекта:

Код: Выделить всё
```
DQD.ForkPTY
```
создает библиотеку, на которую можно ссылаться, и упаковывает ее в пакет NuGet, который использует QBX.
Код: Выделить всё
```
DQD.ForkPTY.Playground
```
ссылается на DQD.ForkPTY внутри решения, а не как на пакет NuGet.

Код: Выделить всё

DQD.ForkPTY.Playground

компилируется, но сразу же аварийно завершает работу во время выполнения. В выходных данных сборки правильно копируется дерево среды выполнения, и libDQD.ForkPTY.Native.Linux.so находится в нужном месте, но DQD.ForkPTY.Playground.deps.json не обновляется, поэтому загрузка собственной библиотеки не перенаправляется. Он сканирует собственную библиотеку в BaseDirectory AppContext и путь загрузки библиотеки, но нигде больше.
Это может быть ошибкой/недосмотром в самой платформе, но мое первое предположение заключается в том, что я просто пропускаю какой-то шаг и делаю его не совсем правильно.

1774882579

Anonymous

У меня есть решение, содержащее проект библиотеки классов. Этот проект библиотеки классов включает в себя собственную библиотеку, которую я помещаю в подкаталог runtimes//native. У меня есть .csproj, настроенный для упаковки файлов библиотеки в папку среды выполнения внутри файла .nupkg, и когда я создаю 
 для этого построенного пакета, deps.json потребляющего проекта обновляется, чтобы найти собственную библиотеку в папке каждого RID.
Но если я сделаю ссылку проекта на библиотеку классов в том же решении, этот проект deps.json не заполняется необходимой информацией.
Итак, код, который ссылается на эту библиотеку классов как на пакет NuGet, работает, но если этот 
 заменить на , тот же код не запустится, поскольку он не знает, где найти собственный файл библиотеки.
Есть ли способ настроить библиотеку классов .csproj чтобы ссылки на проекты в одном решении получали ту же правильную конфигурацию deps.json, что и проекты, которые ссылаются на него через пакет NuGet?
ETA: чтобы увидеть это в действии, клонируйте эти два проекта:
https://github.com/logiclrd/QBX
https://github.com/logiclrd/DQD.ForkPTY
Вы должен иметь возможность компилировать и запускать QBX на Linux x64. (Целью DQD.ForkPTY является поддержка нескольких платформ, но опубликованная в настоящее время версия находится на ранней стадии и на данный момент поддерживает только linux-x64.)
QBX включает DQD.ForkPTY в качестве 
. В результатах сборки вы должны увидеть дерево папок среды выполнения, включающее файл libDQD.ForkPTY.Native.Linux.so и файл deps.json, который направляет запуск linux-x64 к этому файлу.
Теперь откройте решение DQD.ForkPTY. В нем есть два проекта:
[list]
[*][code]DQD.ForkPTY[/code] создает библиотеку, на которую можно ссылаться, и упаковывает ее в пакет NuGet, который использует QBX.
[*][code]DQD.ForkPTY.Playground[/code] ссылается на DQD.ForkPTY внутри решения, а не как на пакет NuGet.
[/list]
[code]DQD.ForkPTY.Playground[/code] компилируется, но сразу же аварийно завершает работу во время выполнения. В выходных данных сборки правильно копируется дерево среды выполнения, и libDQD.ForkPTY.Native.Linux.so находится в нужном месте, но DQD.ForkPTY.Playground.deps.json не обновляется, поэтому загрузка собственной библиотеки не перенаправляется. Он сканирует собственную библиотеку в BaseDirectory AppContext и путь загрузки библиотеки, но нигде больше.
Это может быть ошибкой/недосмотром в самой платформе, но мое первое предположение заключается в том, что я просто пропускаю какой-то шаг и делаю его не совсем правильно. :-)