Если ваш проект использует csproj «старого» стиля с packages.config, первым шагом будет переход на использование PackageReference. Вот несколько документов . Как говорится в документации, есть некоторые различия между тем, как работает package.config и PackageReference. Если на вас это влияет, вы заблокированы, пока не сможете заставить свой проект работать с PackageReference.
Если в вашем проекте используется csproj «старого» стиля с PackageReference (например, вы выполнили миграцию выше), затем перейдите на csproj на основе SDK, чтобы можно было выполнить сборку с помощью CLI dotnet. Вот сообщение в блоге с деталями, как это сделать. . Обратите внимание, что вы можете продолжать использовать Windows .NET Framework с SDK csproj. Хотя csproj на основе SDK появился одновременно с .NET Core, нет необходимости использовать .NET Core с новым стилем проекта. Если ваш проект является библиотекой классов или консольным приложением, у вас определенно все в порядке, в противном случае вам нужно изучить, совместим ли тип проекта с проектами SDK.
После того, как ваш проект .NET Framework работает с SDK-проектами, либо измените TargetFramework на netcoreapp или netstandard, либо вы можете нацелить свой проект, изменив TargetFramework на TargetFrameworks, и использовать полу- Разделенный двоеточиями список TFM, на которые вы хотите нацелиться. Например <TargetFrameworks>net461;netcoreapp2.1</TargetFrameworks>. Затем просто запустите dotnet restore, и если какой-либо из используемых вами пакетов не будет совместим с .NET Core, восстановление завершится неудачно, и вы просто вернетесь к цели .NET Framework.
Таким образом, если ваш проект использует csproj на основе SDK, то для проверки совместимости ваших зависимостей с .NET Standard / .NET Core требуется 10 секунд. Если ваш проект еще не использует csproj на основе SDK, вы отменяете свое изменение в строке TargetFramework (s) в вашем csproj и продолжаете свою жизнь до следующего повторного тестирования. Если вы еще не используете csproj на основе SDK и ничто не мешает вам сделать это, тогда обновление будет с низким риском и принесет некоторые преимущества, такие как меньшее количество конфликтов слияния в файле, намного проще создавать nupkgs для любых пакетов, которые вы поддерживать и проверять совместимость с .NET Core за считанные секунды.
Альтернатива: если вы не можете или не хотите мигрировать в проекты на основе SDK и хотите проверить, совместимы ли ваши зависимости, используйте dotnet new classlib для создания нового проекта .NET Core, добавьте ссылки на пакеты к тому же пакеты, которые использует ваш существующий проект, затем попытайтесь восстановить. Если у вас есть большое решение с большим количеством проектов и / или ссылок, просто напишите небольшую программу для чтения ваших файлов packages.config / csproj в формате XML, найдите уникальный список используемых пакетов, а затем напишите новый таргетинг на основе SDK на основе csproj. .NET Core со всеми пакетами, которые вы только что нашли в качестве ссылок на пакеты.