Отсутствие собственных зависимостей DLL в потребляющих проектах - PullRequest
0 голосов
/ 30 октября 2019

Я создал проект библиотеки классов с использованием C # и .Net.

В этом проекте я использовал две внешние зависимости (точнее: Microsoft.Win32.Registry (4.6.0) и System.Data. SqlClient (4.7.0) Nuget пакеты).

После того, как я собрал этот проект, я могу увидеть сгенерированный файл DLL в папке / bin / debug.

Теперь я хочу импортировать эту сгенерированную DLLв другом проекте и потреблять его методы. После импорта, и я запускаю этот проект, он жалуется на невозможность найти те две внешние зависимости, которые были у меня в проекте библиотеки классов.

В качестве временного исправления я могу импортировать эти две отсутствующие ссылки в этом проекте, и онбудет работать нормально и как положено. Но это не то, что я хочу (и я думаю, что это не чистое решение).

Я хочу знать, почему зависимости проекта библиотеки классов не отражаются в сгенерированном файле DLL? И есть ли способ исправить это?

Большое спасибо за вашу помощь.

Ответы [ 2 ]

0 голосов
/ 30 октября 2019

Если ваша библиотека классов находится в том же решении или в репозитории управления исходным кодом, что и приложение, в котором она используется, вам следует использовать ссылку "проект-проект" вместо прямой ссылки на сборку. Как говорят документы, таким образом, он автоматически обнаруживает изменения в библиотеке классов, когда вы компилируете приложение, но то, что документы не сказали, это то, что зависимости тоже текут.

В противном случае, как писал Лэнс Ли,Вы должны создать пакет NuGet из вашей библиотеки классов. К сожалению, есть немного барьера, чтобы начать. Создать пакет легко, но тогда вам нужно где-нибудь опубликовать файл nupkg. Для ранней разработки (до того, как пакет будет готов к распространению), самый простой вариант - использовать локальный файл . Затем вам понадобится nuget.config в приложении, которое будет использовать пакет для добавления этого локального канала в качестве источника, затем вы можете установить пакет в вашем потребляющем проекте, что принесет зависимости.

Как видите, для разработки это медленно и сложно, потому что, если ваше приложение-потребитель находит ошибку в вашем пакете, или если вы пытаетесь разработать новую функцию как в приложении-потребителе, так и в библиотеке классов нав то же время это означает, что каждый раз, когда вы вносите изменения в код библиотеки классов, вам нужно увеличить номер версии, упаковать пакет, опубликовать пакет, а затем обновить версию пакета в потребляющем проекте. Гораздо проще использовать ProjectReference, который позволяет просто редактировать код, компилировать и запускать. Больше не о чем думать.

0 голосов
/ 30 октября 2019

См. this , способ, которым вы ссылаетесь на эту сборку, не рекомендуется, когда оба проекта находятся на одном компьютере.

Вы используете ссылку на файл (Добавить ссылку =>просматривать...). И именно поэтому вы должны импортировать эти две отсутствующие ссылки в этом проекте вручную.

Поэтому я предлагаю вам добавить ссылку на проект, если оба проекта находятся в одном решении, вы можете right-click current project=>add reference=>project tab find that assembly you need. (Вместо просмотра ...)

Если указанный проектне в том же решении. Щелкните правой кнопкой мыши решение в обозревателе решений => добавить существующий проект, чтобы импортировать его. Затем добавьте ссылку на проект.

...