Ссылка на старую (полную .NET Framework) библиотеку классов при нацеливании на .NET Core

Я разрабатываю веб-приложение на .Net Core, но, поскольку .Net Core все еще находится в разработке, некоторые используемые библиотеки еще не созданы на Core.

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

Я знаю, что таким образом я теряю многоплатформенные возможности, но на самом деле мне это не нужно в данный момент, мне нужно продолжать использовать API и унифицированный конвейер MVC, интегрированный контейнер зависимостей Ingnection и другие новые функции .Net Core.

Будет ли это возможно, ориентируясь на старый фреймворк?


asp.net-core asp.net-core-webapi asp.net-core-mvc .net-core-rc2
person ilFusta    schedule 28.10.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Короткий и простой ответ: вы не можете ссылаться на библиотеки .NET Framework 4.x в проекте .NET Core по той простой причине, что это две разные платформы и многие API-интерфейсы, которые были доступны в .NET 4.5/4.6, недоступны в .NET. Основной.

Однако есть некоторые исключения.

  1. Если ваша библиотека классов нацелена на portable-net45-win8, вы можете ее использовать.

    Поскольку этот профиль гарантирует, что поверхность API соответствует той, которую использует .NET Core, и основана на System.Runtime. Чтобы иметь возможность импортировать такие пакеты/библиотеки в приложение .NET Core или библиотеку классов .NET Core, вам необходимо добавить

    "frameworks:" {
  "netcoreapp1.0": {
    "dependencies : { },
    "imports": [ "dotnet5.6", "portable-net45-win8" ] 
  }      
}

  2. Если ваша библиотека классов нацелена на dnx5x/dotnet5.x, то их можно использовать так же, как указано выше.

  3. Если вы действительно уверены, ваша библиотека классов не использует НИКАКОЙ неподдерживаемый API и ни одна из ее зависимостей не использует НИКАКОЙ em> неподдерживаемый API

    Тогда вы могли бы технически использовать тот же трюк, но я бы посоветовал НИКОГДА не делать этого, так как это позволит вам импортировать любую библиотеку .NET 4.x (даже 2.0), и вы никогда не узнаете, если он поддерживается или нет. ПОЭТОМУ НЕ ДЕЛАЙТЕ ЭТОГО НИКОГДА.

    Вместо этого преобразуйте свою библиотеку классов в переносимую библиотеку классов и настройте netstandard1.x (зависит от версии .NET Framework, которая использовалась ранее, см. это matrix).

    Например, если ваша библиотека классов ранее предназначалась для .NET Framework 4.5.1, преобразуйте ее в netstandard1.2. Если есть какие-либо ошибки об отсутствующем API, значит, использовались API, не поддерживаемые .NET Core. Вам придется это исправить (удалите его из версии netstandard1.2 с помощью директивы прекомпилятора #if !NETSTANDARD1_2 или попробуйте более высокую версию сетевого стандарта. Вы также можете указать две цели в новых библиотеках классов project.json absed.

person Tseng    schedule 28.10.2016
comment
Спасибо за ваш ответ, в моем конкретном случае мне нужно использовать библиотеку Openstack.Net для подключения к службам CloudFiles. Если я правильно понял, мне просто нужно проверить, какую версию фреймворка он поддерживает, добавить ее в раздел импорта, а затем установить пакет nuget, и, надеюсь, он будет работать, верно? - person ilFusta; 28.10.2016
comment
@ilFusta, вы можете создать основное приложение asp.net, ориентированное как на ядро ​​.net, так и на полную платформу .net. Но в тот момент, когда вы создаете ссылку на пакет, для которого требуется полная платформа .net, ваше приложение будет работать только на полной платформе .net. Я предполагаю, что Visual Studio выдает ошибку с просьбой удалить ссылку на ядро ​​.net. - person Fabricio Koch; 28.10.2016

arrow_upward
0
arrow_downward

Да, это возможно. У меня есть проект, ориентированный на NHibernate (который зависит от полной .NET Framework), а также некоторые проекты библиотеки классов старого формата (csproj).

Я использую DI и MVC/API без проблем.

person Fabricio Koch    schedule 28.10.2016
comment
Это очень вряд ли сработает, если вы не злоупотребляете свойством import в project.json, а если вы злоупотребляете им (используете его неправильным/непреднамеренным образом), в лучшем случае оно будет работать в Windows, но не будет работать в Linux в некоторых случаях (зависит от того, какой API находится внутри библиотеки и какие из этих API фактически используются - person Tseng; 28.10.2016
comment
@Tseng в вопросе он упомянул, что знает, что решение не будет работать в других средах. Я просто сказал, что это возможно. Это не лучшее решение, но возможно. - person Fabricio Koch; 28.10.2016