Использование .net Standard 1.5 lib в .net 4.6.2 пропускает System.Runtime 4.1.0.0

У меня возникла проблема при использовании стандарта .net в консольных приложениях .net framework 4.6.2.

Я мог бы свести проблему к следующему: Учитывая:

Я создаю стандартную клиентскую библиотеку .net 1.5 по сравнению с 2017 годом с этим единственным классом.

public class Class1
    {
        public List<int> Get()
        {
            return new List<int>() { 1, 2, 3, 4, 5, 65, 6 };
        }
    }

Теперь я создаю новое консольное приложение .net 4.6.2, которое просто вызывает метод этого класса:

       static void Main(string[] args)
        {
            var foo = new Class1();

            Console.WriteLine("Done!");
            Console.ReadLine();
        }

Теперь я получаю

System.IO.FileNotFoundException: «Файл или сборка «System.Runtime, версия = 4.1.0.0, культура = нейтральная, PublicKeyToken = b03f5f7f11d50a3a не найдена.

Когда я добавляю пакет .net standardlib nuget в консоль .net fx, он работает. но тогда system.runtime будет доступен через GAC и через ссылку nuget, что кажется мне довольно уродливым.

Я разместил это короткое тестовое решение здесь: https://github.com/Gentlehag/NetStandardSample

Что мне не хватает?


.net c# .net-standard visual-studio-2017 .net-standard-1.5
person Boas Enkler    schedule 08.01.2017    source источник

Ответы (2)


arrow_upward
9
arrow_downward

Я добавил репозиторий, в котором показано, как это сделать. Из README.md:

Требования

Вообще говоря, использование библиотек, предназначенных для .NET Standard, в приложении, предназначенном для .NET Framework, требует, чтобы проект приложения включал ссылку NuGet для .NET Standard (NETStandard.Library). Это гарантирует, что в приложение включен правильный набор сборок.

В Visual Studio 2015 по умолчанию для получения пакетов NuGet из проектов .NET Framework используется packages.config. Я не рекомендую этот путь, так как это означает, что все сборки внедряются напрямую в проект приложения, что значительно раздует ваш файл проекта. Вместо этого я рекомендую вам использовать project.json. Для этого выполните следующие шаги:

  1. Удалите все пакеты (если вы все еще используете packages.config)
  2. Удалите пустой packages.config

  3. Добавьте файл project.json с таким содержимым:

    json { "dependencies": { "NETStandard.Library": "1.6.0" }, "runtimes": { "win": {} }, "frameworks": { "net462": {} } }

Обратите внимание, что обычно вы можете полагаться на последнюю версию пакета NETStandard.Library, но вам необходимо убедиться, что прозвище фреймворка синхронизировано с версией .NET Framework, на которую нацелено ваше приложение, т. е. когда вы ориентируетесь на .NET Framework. 4.6.1, вам нужно убедиться, что вместо этого используется net461.

Это кажется неуклюжим

Да, это. Мы планируем решить эту проблему двумя способами:

  • Мы заменяем project.json решением на основе MSBuild в Visual Studio 2017. Вам по-прежнему нужно будет добавить ссылку на NETStandard.Library, но вам больше не нужно возиться с тем, как представляются пакеты, или вручную синхронизировать информацию о таргетинге. .

  • Мы планируем обновить .NET Framework, чтобы в будущих версиях была встроенная поддержка .NET Standard, и в этом случае эта ссылка больше не понадобится.

person Immo Landwerth    schedule 09.01.2017
comment
Большое спасибо за его разъяснение. как мне добавить пакет в VS2017 RC? Там у меня больше нет package.json, и я не уверен, есть ли эквивалентная замена для раздела зависимостей? - person Boas Enkler; 10.01.2017
comment
В VS2017 мы заменили project.json новой группой элементов MSBuild <PackageReference>. Это даже проще, чем project.json. Для приложений .NET Framework мы разрешим вам использовать package.config или способ MSBuild, и, насколько я знаю, план состоит в том, чтобы предложить вам при первом использовании. Однако я не думаю, что это доступно в текущем RC VS2017. Я спрошу. - person Immo Landwerth; 11.01.2017

arrow_upward
0
arrow_downward

Я обнаружил, что добавление NETStandard.Library не сработало для меня, но обеспечение того, чтобы перенаправления привязки генерировались при сборке, помогло. Для этого вы должны убедиться, что у вас есть

<PropertyGroup>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
</PropertyGroup>

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

<PropertyGroup>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>

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

Вы можете найти более подробную информацию о проблемах здесь: https://github.com/dotnet/announcements/issues/31

person adrian    schedule 28.09.2017