ответ «прямо и точно»: вам не нужно об этом беспокоиться.Когда вы устанавливаете или обновляете пакет в проекте, NuGet сообщает системе проекта, что поместить в csproj.Обратите внимание, что это не то же самое, что восстановление пакетов.Установка пакетов в проекте packages.config означает, что Visual Studio изменит и файл packages.config, и файл csproj.Если на вашем компьютере нет пакета nuget, когда NuGet загружает и извлекает его, это называется восстановлением, а не установкой.В предыдущем вопросе вы сказали, что клонировали чужое репо и пытаетесь его построить.Вы можете спросить их, как / почему csproj не соответствует пакету log4net на nuget.org.Или в Visual Studio нажмите ctrl-q, чтобы перейти к поиску, введите «консоль диспетчера пакетов» и выберите его.После инициализации выберите проект с неверной ссылкой log4net в раскрывающемся списке «Проект по умолчанию», затем введите Update-Package -reinstall.Это должно это исправить.В качестве альтернативы вы можете щелкнуть правой кнопкой мыши проект в обозревателе решений, выбрать Управление пакетами NuGet, удалить log4net, а затем установить его снова.Вы также можете рассмотреть возможность миграции из packages.config в PackageReference , у которого нет этой проблемы пути к подсказке, которая есть в файле packages.config. Длинный подробный ответ
: при использовании NuGet слово«версия» обычно относится к версии пакета, в данном случае 1.2.11.Глядя на страницу пакета на nuget.org , в истории версий мы можем видеть другие версии, такие как 1.2.10, 2.0.0, 2.0.1 вплоть до 2.0.8.Если у вас нет нескольких проектов, каждый из которых ссылается на свою версию пакета, NuGet не загружает несколько версий.
.NET имеет разные версии среды выполнения, некоторые из которых несовместимы с другими, но они называютсяTikt Framework Monikers (TFM), хотя люди, которые не работают в Microsoft, обычно называют их целевой структурой или чем-то в этом роде.Он похож на другие управляемые среды выполнения или языки сценариев, такие как Java, Python, PHP и т. Д., Но, возможно, более сложный, поскольку в прошлом было создано огромное количество TFM, в основном для разных мобильных устройств, которые имели разные возможности.Кроме того, среда выполнения Windows разделена на 3 «семейства», в которых TFM обратно совместимы, но только в пределах одного «семейства».* Nuget Client имеет сложное сопоставление совместимых TFM , которые он использует для выбора ближайшего совместимого TFM в пакете NuGet для вашего проекта.
Еще одна причина, по которой пакет может содержать несколько dll для разныхTFM - это потому, что они хотят использовать более новые API в более новых TFM, в то же время позволяя проектам, нацеленным на более старую TFM, использовать пакет без новых API.Например, хотя net45, net46, net47 и вскоре net48 совместимы с net40, net40 не поддерживала async-await.Таким образом, пакет может иметь net40 dll, поэтому проекты, нацеленные на net40, все еще могут использовать пакет, но пакет также может содержать net45 dll с дополнительными асинхронными API.net1x, net 2x и net3x настолько стары (как net40 и net45), что пакеты редко предоставляют dll для этих старых версий.Тем не менее, log4net 1.2.11 был выпущен в 2011 году, когда эти старые TFM, вероятно, все еще были достаточно распространены, поэтому их совместимость стоила того.
Итак, то, что вы видите в папке lib пакета log4net, не являетсяразные версии log4net, на самом деле это одна и та же версия log4net, но скомпилированная для разных TFM.Это увеличивает количество проектов, которые могут использовать пакет.
Существует несколько возможностей, по которым используемый вами проект имеет HintPath, которого не существует. Учитывая предоставленную вами информацию, похоже, что кто-то вручную отредактировал csproj, или кто-то создал свой собственный пакет nuget log4net v1.2.11, в котором dll находится в другом месте внутри nupkg по сравнению с пакетом на nuget. орг. Пакеты NuGet спроектированы так, чтобы быть неизменными, то есть загрузка nupkg с определенным идентификатором (именем) пакета, а версия пакета должна быть идентичной всем другим nupkg с таким же идентификатором пакета + версия из любого другого канала NuGet. Если это не так, вы можете получить ошибки сборки, когда NuGet восстанавливает пакет из другого источника по сравнению с человеком, который установил пакет.
Наконец, NuGet с packages.config не предназначен для редактирования вручную. Вы не должны редактировать и сохранять файл packages.config или References или HintPath в csproj самостоятельно. Используйте интерфейс диспетчера пакетов NuGet или консоль диспетчера пакетов для установки, удаления и обновления пакетов. В клиенте NuGet есть много логики, а не только выбор активов, который вы ошибетесь, если пакет использует определенные функции.
В Visual Studio 2017 NuGet добавил новый способ ссылки на пакеты, называемый PackageReference. Вам может понадобиться перейти в Сервис-> Параметры, найти NuGet Package Manager-> General и либо изменить формат управления пакетами по умолчанию, либо включить «разрешить выбор формата при первой установке пакета». Также должна быть возможность щелкнуть правой кнопкой мыши многие типы проектов и иметь возможность мигрировать в PackageReference, но это не было включено для всех типов проектов (в основном ASP.NET). PackageReference не поддерживает некоторые функции, которые поддерживает package.config, а некоторые типы проектов также не поддерживают PackageReference. Но в большинстве распространенных случаев он поддерживается, и, если вы можете его использовать, у него есть несколько преимуществ, в том числе отсутствие указания пути подсказки в вашем csproj и избежание конкретной проблемы, которая у вас есть в данный момент (при восстановлении NuGet записывает файл obj\project.assets.json, который содержит пути к выбранным ресурсам, которые использует компилятор, то есть, если вы измените структуру репозитория исходного кода, простое восстановление NuGet исправит это, тогда как с packages.config вам может потребоваться переустановить каждый пакет в каждом проекте ). Проекты, использующие новый стиль SDK, который был представлен в .NET Core, вообще не поддерживают packages.config, во что бы то ни стало.
вау, я бродил гораздо дольше, чем ожидал. Надеюсь, это помогло вам больше, чем смутило.