Как автоматически развернуть C # DLL со скрытой зависимостью NuGet при смешивании .Net Standard и .Net Framework?

Question

Как автоматически развернуть C # DLL со скрытой зависимостью NuGet при смешивании .Net Standard и .Net Framework?

2

У меня есть решение Visual Studio (2017) С#, которое имеет следующую структуру:

Решение
- ExeProject
- DLLProject
  - Пакет NuGet-Dependency to Stateless (название пакета - "Без состояния")

DLLProject скрывает зависимость в своих интерфейсах, т.е. предполагается, что использование библиотеки Stateless является деталью реализации DLLProject.

ExeProject доступ только к общедоступным интерфейсам и фабрикам DLLProject.

По причинам, выходящим за рамки этого вопроса, ExeProject ориентирован на .Net Framework 4.6.1, а DLLProject ориентирован на .Net Standard 2.0.

Это компилируется нормально, но при отладке Stateless.dll не найден исполняемым файлом.

Можно ли автоматически развертывать этот DLL при связывании с DLLProject без добавления Stateless зависимости NuGet к ExeProject?

Tim Meyer 18 апр. 2019, в 08:10

Источник

0

Почему вы хотите избежать добавления зависимости от nuget? Это именно то, для чего они предназначены.
Bradley Uffner 18 апр. 2019, в 11:55
0

@BradleyUffner Поддерживаемость, совместимость, тестируемость, разделение интерфейса и т. Д. Я хочу иметь возможность изменять / отключать / удалять соответствующую библиотеку без необходимости изменять ExeProject . Это не так важно в приведенном мною минимальном примере, но в реальной задаче есть множество таких проблем.
Tim Meyer 18 апр. 2019, в 17:50
0

Можете ли вы сделать DLLProject .Net Framework 4.6.1? Должно "просто работать", если все в одном решении.
mxmissile 18 апр. 2019, в 18:04
0

@mxmissile DLLProject дополнительно используется в средах, где .Net Framework недоступен, поэтому, к сожалению, нет.
Tim Meyer 18 апр. 2019, в 18:21

Показать ещё 2 комментария

Теги:

c#

.net

nuget

1 ответ

Ещё вопросы

Почему вы хотите избежать добавления зависимости от nuget? Это именно то, для чего они предназначены.
@BradleyUffner Поддерживаемость, совместимость, тестируемость, разделение интерфейса и т. Д. Я хочу иметь возможность изменять / отключать / удалять соответствующую библиотеку без необходимости изменять ExeProject . Это не так важно в приведенном мною минимальном примере, но в реальной задаче есть множество таких проблем.
Можете ли вы сделать DLLProject .Net Framework 4.6.1? Должно "просто работать", если все в одном решении.
@mxmissile DLLProject дополнительно используется в средах, где .Net Framework недоступен, поэтому, к сожалению, нет.

Lesiak · Answer 1 · 2019-04-18T09-42-00.000Z

В .NET Core эти переходные зависимости NuGet работают автоматически.

В .NET Framework есть опция "Копировать локальный" для библиотек, на которые есть ссылки. Убедитесь, что для проблемного установлено значение True.

Обновить

Для вашего случая,.NET Framework App и .NET Standard lib, для установки требуется ручное изменение файла .c Framework app.csproj. Пожалуйста, следуйте: Скопируйте все зависимости из библиотек .Net Standard в консольное приложение .Net Framework.

Мой проект Exe нацелен на .NET Framework (в частности, на десктопы), а DLL на .Net Standard. Я обновил вопрос, чтобы включить эту деталь. Есть ли шанс заставить его работать автоматически в этом случае?