Visual Studio 2017 неправильно разрешает конкретную ссылку

Question

В моем решении есть несколько проектов, которые ссылаются на System.ValueTuple.dll через nuget.Путь к сборке определен одинаково для всех этих проектов, но Visual Studio 2017 разрешает его по-разному.Это приводит к тому, что большинство проектов приходится строить снова и снова, хотя изменений нет.

Вот пример определения ссылки в файле проекта (опять же, она одинакова для всех проектов).):

<Reference Include="System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
  <HintPath>..\..\..\..\packages\System.ValueTuple.4.4.0\lib\net461\System.ValueTuple.dll</HintPath>
  <Private>True</Private>
</Reference>

И вот сообщение, которое я получаю, когда Visual Studio неправильно разрешает ссылку на проект и, таким образом, строит ее снова, независимо от того, есть изменения или нет:

Проект «ХХХ» не актуален.Ссылочный источник CopyLocal 'C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Professional \ MSBuild \ Microsoft \ Microsoft.NET.Build.Extensions \ net461 \ lib \ System.ValueTuple.dll' более поздний, чем 'C:\ Src \ Current.Release \ Bin \ Debug \ System.ValueTuple.dll '.

Почему Visual Studio не берет указанную мной ссылку или просто отказывает, если ее там нет?В окне свойств ссылок также отображается неверный путь.

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

Надеюсь, вы, ребята, сможете мне помочь.Заранее спасибо!

Answer 1

Visual Studio 2017 неправильно разрешает конкретную ссылку

Это потому что:

Это связано с добавленной поддержкой NETStandard2,0.Мы внедряем новые сборки в NET 4.6.1 и более поздние настольные проекты, чтобы добавить поддержку netstandard2.0 .Теперь мы делаем это в целях, а не в пакетах, потому что больше нет необходимости ссылаться на пакет для создания нестандартной библиотеки.Это внедрение происходит всякий раз, когда мы видим ссылку на библиотеку netstandard 1.5 или выше (см. Dotnet / sdk # 1386).

Чтобы решить эту проблему, вы можете добавить перенаправление привязки к этим ссылкам.

Проверьте System.Net.Http v4.2.0.0, который копируется / загружается из инструментария MSBuild для получения более подробной информации.

Надеюсь, это поможет.

Answer 2

Я чувствую твою боль.Были похожие проблемы с System.Net.Http.Многое из того, что я собираюсь сказать, является анекдотичным и недоделанным в моей голове.Как я понимаю, MS начала отходить от отдельных системных nupkgs в пользу поставки библиотек DLL со структурой:

Мы завершим все эти пакеты с намерением, что они станутчасть фреймворка снова в .net 4.7.1.Цель netstandard2 - остановить всю модель переносимости на основе пакетов из-за всех этих проблем.

Я думаю, что VS 2017 имеет особую логику:

Я не понимаю, что вы имеете в виду.Когда вы используете последний пакет NuGet, он содержит информацию ВНУТРИ пакета, чтобы использовать DLL-библиотеку FRAMEWORK вместо целевого .NET Framework 4.5+.Это полностью преднамеренное поведение / настройка пакета NuGet. (см. Комментарий Карела в 04:45)

еще один комментарий, детализирующий наблюдения, аналогичные вашим

Кроме того, учитывая, что вы являетесь VS2017, вы бы рассмотрели элемент <PackageReference вместо packages.config файла?