Мучаю тут на досуге .NET Standard. Запилил в одном солюшене библиотеку на .NET Standard 1.3 и проект для тестов MSTest этой библиотеки на .NET Framework 4.6. Компилируется всё, но при попытке выполнения теста в методе библиотеки валится исключение:

System.IO.FileNotFoundException: Не удалось загрузить файл или сборку "System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" либо одну из их зависимостей. Не удается найти указанный файл.

При том, что в зависимостях библиотеки System.Net.Http только версии 4.3.1

Попробовал создать рядом тестовый проект на .NET Core с точно тем же тестовым методом — он отрабатывает без проблем.

Куда копать?

Здравствуйте, karbofos42, Вы писали:

K>Попробовал создать рядом тестовый проект на .NET Core с точно тем же тестовым методом — он отрабатывает без проблем.

K>Куда копать?

Вариант 1: поставить редирект на System.Net.Http, Version=4.0.0.0, есть шанс отхватить разнообразные TypeLoadException
Вариант 2: ждать netstandard 2 и тулинга в студии для него. До этого страдать

Здравствуйте, karbofos42, Вы писали:

K>

K>System.IO.FileNotFoundException: Не удалось загрузить файл или сборку "System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" либо одну из их зависимостей. Не удается найти указанный файл.

K>При том, что в зависимостях библиотеки System.Net.Http только версии 4.3.1

Не путай версию пакета и версию сборки, конкретно у этого они точно отличаются. Ну и почитай про binding refirect.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, karbofos42, Вы писали:

K>>Попробовал создать рядом тестовый проект на .NET Core с точно тем же тестовым методом — он отрабатывает без проблем.

K>>Куда копать?

S>Вариант 1: поставить редирект на System.Net.Http, Version=4.0.0.0, есть шанс отхватить разнообразные TypeLoadException
S>Вариант 2: ждать netstandard 2 и тулинга в студии для него. До этого страдать

Я через Nuget в тестовый проект итоге добавил System.Net.Http сначала последней версии 4.3.2, но в итоге всё равно была ошибка версии, пришлось конфиг прописать:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http"
          publicKeyToken="b03f5f7f11d50a3a" />
        <bindingRedirect oldVersion="4.1.1.0" newVersion="4.1.1.1" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

но потом подумал, что это как-то не то и просто взял версию 4.3.1.

В общем, пошел вспоминать про сборки и читать нормально про NuGet, а пока задам пару, вероятно, глупых вопросов:
1) У меня в библиотеке на .NET Standard 1.3 добавлен пакет https://www.nuget.org/packages/HtmlAgilityPack/1.5.1/
Правильно я понимаю, что меня в данном случае должны волновать только эти зависимости?

.NETStandard 1.3
System.Net.Http (>= 4.3.1)
System.Xml.XmlDocument (>= 4.3.0)
System.Xml.XPath (>= 4.3.0)
System.Xml.XPath.XmlDocument (>= 4.3.0)

И без разницы из .NET Core или .NET Framework 4.6 впоследствии будет вызываться?
2) Как ориентироваться в случае, если у пакета указаны зависимости, например, только для .NETStandard 1.1, 1.3 и 1.6, а я использую его в 1.4? Смотреть по ближайшей младшей версии 1.3?
3) Вот я в свою библиотеку через NuGet подтянул HtmlAgilityPack, которому по идее важно только, чтобы версия System.Net.Http была >= 4.3.1, для чего заботливо подтянулся System.Net.Http версии 4.3.1.
Когда я свою библиотеку подключаю к .NET Core 1.1, то её устраивает и версия 4.3.2, входящая в SDK. Когда же я её добавляю в .NET FW 4.6, то ищется строго версия 4.3.1. Как-то можно изменить, чтобы и моя библиотека всегда хотела версию >= 4.3.1?
4) Или самому тоже свою библиотеку собирать в разных вариантах или плодить "ненужные" зависимости? Например, HtmlAgilityPack в варианте под .NET Framework не требует никаких дополнительных зависимостей, я пишу свою библиотеку под .NET Standard (потому что типа стильно, модно, молодёжно, универсально и т.д. и т.п.) и добавляются зависимости в виде того же System.Net.Http (>= 4.3.1). Использую свою библиотеку опять в .NET Framework и приходится разбираться с зависимостями чисто из-за .NET Standard, т.к. их не было бы, если бы всё было под .NET Framework.

Здравствуйте, karbofos42, Вы писали:

K>1) У меня в библиотеке на .NET Standard 1.3 добавлен пакет https://www.nuget.org/packages/HtmlAgilityPack/1.5.1/
K>Правильно я понимаю, что меня в данном случае должны волновать только эти зависимости?
Ага, вот этот момент я пропустил, позор мне
Надо было сразу спросить. Да, при подключении сторонних пакетов надо внимательно изучать зависимости для target platform (указывается в свойствах проекта)
И те же пакеты (перечисленные в зависимостях) добавлять в библиотеки, которые ссылаются на твою библиотеку. Обычно библиотеку оформляют в нюгет-пакет, чтобы самому не следить за зависимостями.

K>2) Как ориентироваться в случае, если у пакета указаны зависимости, например, только для .NETStandard 1.1, 1.3 и 1.6, а я использую его в 1.4? Смотреть по ближайшей младшей версии 1.3?
Да, будет она использоваться. Проверить можно по свойствам assembly reference, будет путь вида

packages\<пакет>\...\<target_fw>\library.dll

target_fw соответствует одному из target framework moniker.

K>3) Вот я в свою библиотеку через NuGet подтянул HtmlAgilityPack, которому по идее важно только, чтобы версия System.Net.Http была >= 4.3.1, для чего заботливо подтянулся System.Net.Http версии 4.3.1.
K>Когда я свою библиотеку подключаю к .NET Core 1.1, то её устраивает и версия 4.3.2, входящая в SDK. Когда же я её добавляю в .NET FW 4.6, то ищется строго версия 4.3.1. Как-то можно изменить, чтобы и моя библиотека всегда хотела версию >= 4.3.1?
Да, оформить библиотеку как нюгет-пакет, прописать зависимости в nuspec-пакете. С тулингом для netstandard 2 можно будет попросить студию генерить пакет при сборке.

K>4) Или самому тоже свою библиотеку собирать в разных вариантах или плодить "ненужные" зависимости?
Или собирать только под реально используемый fw, или под самый общий и распространять нюгет-пакетом. Во втором варианте прописывать в нюгет-зависимостях только HtmlAgilityPack (остальное подтянется нюгетом в зависимости от платформы).
В разных вариантах имеет смысл собирать, только если свой код зависит от целевой платформы.

Здравствуйте, karbofos42, Вы писали:

K>И без разницы из .NET Core или .NET Framework 4.6 впоследствии будет вызываться?
K>2) Как ориентироваться в случае, если у пакета указаны зависимости, например, только для .NETStandard 1.1, 1.3 и 1.6, а я использую его в 1.4? Смотреть по ближайшей младшей версии 1.3?
K>3) Вот я в свою библиотеку через NuGet подтянул HtmlAgilityPack, которому по идее важно только, чтобы версия System.Net.Http была >= 4.3.1, для чего заботливо подтянулся System.Net.Http версии 4.3.1.
K>Когда я свою библиотеку подключаю к .NET Core 1.1, то её устраивает и версия 4.3.2, входящая в SDK. Когда же я её добавляю в .NET FW 4.6, то ищется строго версия 4.3.1. Как-то можно изменить, чтобы и моя библиотека всегда хотела версию >= 4.3.1?
K>4) Или самому тоже свою библиотеку собирать в разных вариантах или плодить "ненужные" зависимости? Например, HtmlAgilityPack в варианте под .NET Framework не требует никаких дополнительных зависимостей, я пишу свою библиотеку под .NET Standard (потому что типа стильно, модно, молодёжно, универсально и т.д. и т.п.) и добавляются зависимости в виде того же System.Net.Http (>= 4.3.1). Использую свою библиотеку опять в .NET Framework и приходится разбираться с зависимостями чисто из-за .NET Standard, т.к. их не было бы, если бы всё было под .NET Framework.

Проще дождаться 2.0 и внятного тулинга
https://docs.microsoft.com/ru-ru/dotnet/standard/library

Все таки NetStandard это больше для PCL и Core.
А пока проще собирать в разных вариантах

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, karbofos42, Вы писали:

K>>1) У меня в библиотеке на .NET Standard 1.3 добавлен пакет https://www.nuget.org/packages/HtmlAgilityPack/1.5.1/
K>>Правильно я понимаю, что меня в данном случае должны волновать только эти зависимости?
S>Ага, вот этот момент я пропустил, позор мне
S>Надо было сразу спросить. Да, при подключении сторонних пакетов надо внимательно изучать зависимости для target platform (указывается в свойствах проекта)
S>И те же пакеты (перечисленные в зависимостях) добавлять в библиотеки, которые ссылаются на твою библиотеку. Обычно библиотеку оформляют в нюгет-пакет, чтобы самому не следить за зависимостями.

K>>2) Как ориентироваться в случае, если у пакета указаны зависимости, например, только для .NETStandard 1.1, 1.3 и 1.6, а я использую его в 1.4? Смотреть по ближайшей младшей версии 1.3?
S>Да, будет она использоваться. Проверить можно по свойствам assembly reference, будет путь вида
S>

S>packages\<пакет>\...\<target_fw>\library.dll
S>

S>target_fw соответствует одному из target framework moniker.

K>>3) Вот я в свою библиотеку через NuGet подтянул HtmlAgilityPack, которому по идее важно только, чтобы версия System.Net.Http была >= 4.3.1, для чего заботливо подтянулся System.Net.Http версии 4.3.1.
K>>Когда я свою библиотеку подключаю к .NET Core 1.1, то её устраивает и версия 4.3.2, входящая в SDK. Когда же я её добавляю в .NET FW 4.6, то ищется строго версия 4.3.1. Как-то можно изменить, чтобы и моя библиотека всегда хотела версию >= 4.3.1?
S>Да, оформить библиотеку как нюгет-пакет, прописать зависимости в nuspec-пакете. С тулингом для netstandard 2 можно будет попросить студию генерить пакет при сборке.

K>>4) Или самому тоже свою библиотеку собирать в разных вариантах или плодить "ненужные" зависимости?
S>Или собирать только под реально используемый fw, или под самый общий и распространять нюгет-пакетом. Во втором варианте прописывать в нюгет-зависимостях только HtmlAgilityPack (остальное подтянется нюгетом в зависимости от платформы).
S>В разных вариантах имеет смысл собирать, только если свой код зависит от целевой платформы.

Вот так я пару лет назад хотел заморочиться с PCL, но в итоге понял, что с переносимостью там не очень. Теперь прочитал как здорово всё сделано в .NET Standard, а его тоже еще не допилили, но конечно всяко лучше, чем PCL

Здравствуйте, karbofos42, Вы писали:

K>Вот так я пару лет назад хотел заморочиться с PCL, но в итоге понял, что с переносимостью там не очень. Теперь прочитал как здорово всё сделано в .NET Standard, а его тоже еще не допилили, но конечно всяко лучше, чем PCL
Угу, методом последовательных приближений.

Спасибо, что не Монте-Карло