Как изменить net core на net framework

У меня есть веб-проект проекта .Net Core и по разным причинам хочу преобразовать его в проект .Net Framework.

У меня есть веб-проект проекта .Net Core и по разным причинам хочу преобразовать его в проект .Net Framework.

Есть ли простой способ сделать это, или мне нужно начать снова и импортировать код из предыдущих проектов.

4b9b3361

Ответ 1

Я загрузил основной проект в сообщество VS 2017 RC и откройте *.csproj в текстовом редакторе.

Просто удалите тег

<RuntimeFrameworkVersion>

и замените

<TargetFramework>netcoreapp1.1</TargetFramework>

to

<TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>

И в конце концов в свойствах проекта заданы любые другие фреймворки и reset back (VS перезагружать и восстанавливать *.csproj файл).

Ответ 2

Ни один из ответов здесь не работал у меня. В .Net Core 2 файл project.json больше не существует. Однако я решил эту проблему, выполнив следующие шаги.

1) Я удалил все пакеты nuget из моего существующего проекта.

2) Я создал отдельный проект веб-приложения .net, ориентированный на .net 4.61. Это было для получения пакетов nuget по умолчанию.

3) Я редактировал временный проект .csproj, копировал все узлы PackageReference внутри ItemGroup и вставлял их в мои существующие проекты .csproj.

4) Отредактировал TargetFramework node (внутри PropertyGroup) с «netstandard2» до «net461»

У меня было несколько изменений в пакете для отслеживания и устранения, но в остальном я смог запустить.

Ответ 3

Это работало для меня в VS2017:

Начните с основного веб-проекта .net.

Отредактируйте *.csproj так, чтобы это выглядело так:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="2.1.3" />
    <PackageReference Include="Microsoft.AspNetCore.CookiePolicy" Version="2.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.Http.Abstractions" Version="2.1.1" />
    <PackageReference Include="Microsoft.AspNetCore.HttpsPolicy" Version="2.1.1" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="2.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.RazorPages" Version="2.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.1.1" />
  </ItemGroup>

</Project>

Сохрани и закрой.

Попробуйте запустить проект.

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

Ответ 4

Я сделал это, и это сработало

удалять

"Microsoft.NETCore.App": {
      "version": "1.1.0",
      "type": "platform"
    }

из проекта .json

затем замените часть фреймворков следующим образом:

 "frameworks": {
    "net46": { }
  },

затем восстановите пакеты.

РЕДАКТИРОВАТЬ: Это устарело сейчас.

Ответ 5

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

  • Сначала щелкните правой кнопкой мыши файл .csproj и добавьте следующие
   <TargetFrameworks>netstandard2.0;netcoreapp2.0;net35;</TargetFrameworks>
        <RuntimeIdentifiers>win7-x86;win7-x64</RuntimeIdentifiers> <EnableDefaultCompileItems>false</EnableDefaultCompileItems>

Ответ 6

В моей версии Visual Studio 2017 (15.6.2) после «Выгрузки проекта», щелкнув правой кнопкой мыши и выбрав «Изменить <your project file>, я должен был:

  1. Добавьте узел:

    <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>

  2. Удалить узлы:

    <TargetPlatformIdentifier>UAP</TargetPlatformIdentifier>

    <TargetPlatformVersion Condition=" '$(TargetPlatformVersion)' == '' ">10.0.16299.0</TargetPlatformVersion>

    <TargetPlatformMinVersion>10.0.16299.0</TargetPlatformMinVersion>

    <ProjectTypeGuids>{A5A43C5B-DE2A-4C0C-9213-0A381AF9435A};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

Ответ 7

Мой стандартный проект .net относительно прост с несколькими пакетами Nuget. Я только что изменился

<TargetFramework>netstandard2.0</TargetFramework>

К

<TargetFramework>**net461**</TargetFramework> в разделе PropertyGroup файла .csproj, и это помогло мне. Спасибо Брэндону Баркли за ваш ответ в комментариях.

Ответ 8

добавить ниже в csproj

  <PropertyGroup>
    <TargetFrameworks>netcoreapp2.1;net471</TargetFrameworks>
  </PropertyGroup>

Ответ 9

Здесь было много похожих ответов, но я не увидел ни одного, который бы вполне соответствовал моим действиям, поэтому я хотел бы оставить это здесь на всякий случай, если кто-то еще в той же обуви.

Просто чтобы прояснить, мой проект был консольной программой. Так что, если вы пытаетесь использовать этот ответ для чего-то другого, ваш пробег может отличаться.

В вашем файле .csproj внутри <PropertyGroup></PropertyGroup> измените <TargetFramework> чтобы отразить следующее:

<TargetFramework>net461</TargetFramework>

Теперь в этом примере я использовал v4.6.1. Я могу только предположить, что вы включите свою версию за словом «net», без точек. Удачи!

Источник

try-convert NuGet Badge

This is a simple tool that will help in migrating .NET Framework projects to .NET Core.

How to use it

Install it as a global tool here:

dotnet tool install -g try-convert

If you already have it installed, make sure to update:

dotnet tool update -g try-convert

If you’re using the tool again, make sure you’ve got the latest release: https://github.com/dotnet/try-convert/releases

How to use the tool

Nagivate to the root of your solution and simply execute:

Alternatively, you can do

If you only want to convert a specific subfolder, solution, or project, type:

try-convert -w path-to-folder-or-solution-or-project

If you want more help from the tool, run:

Because this is for converting older .NET Framework (Windows) projects, the tool only works on Windows.

NOTE: Do not use this tool from the Visual Studio developer command prompt. There is special MSBuild resolution that happens there and it ends up being incompatible with the tool. Please use a normal terminal application.

Status

Unit Tests (Debug) Unit Tests (Release)
ci Build Status Build Status
official Build Status Build Status

How to build

Simple: clone the repo and run

To use the tool locally, you need to build it from source. Once it’s built, the tool will live under:

/artifacts/bin/try-convert/Debug/net6.0/try-convert.exe

Alternatively, you can look at the following directory and copy that into somewhere else on your machine:

mv /artifacts/bin/try-convert/Debug/net6.0/publish C:/Users/<user>/try-convert

You can invoke the tool from the publish directory as well.

Support policy

This tool is not supported in any way. Nobody will be on the hook for fixing any issues with it, nor is anyone who builds this tool obliged to add any requested features.

This is an open source project built by members of the .NET team in their spare time. Although we’ll strive to fix issues and add features if people ask for them, the default answer to any issue filed will be, «we’ll review a pull request that implements this».

Who is this tool for?

This tool is for anyone looking to get a little help migrating their projects to .NET Core (or .NET SDK-style projects).

As the name suggests, this tool is not guaranteed to fully convert a project into a 100% working state. The tool is conservative and does as good of a job as it can to ensure that a converted project can still be loaded into Visual Studio and build. However, there are an enormous amount of factors that can result in a project that may not load or build that this tool explicitly does not cover. These include:

  • Complex, custom builds that you may have in your solution
  • API usage that is incompatible with .NET Core
  • Unsupported project types (such as Xamarin, WebForms, or WCF projects)

If the bulk of your codebase is generally capable of moving to .NET Core (such as lots of class libraries with no platform-specific code), then this tool should help quite a bit.

It is highly recommended that you use this tool on a project that is under source control.

What does the tool do?

It loads a given project and evaluates it to get a list of all properties and items. It then replaces the project in memory with a simple .NET SDK based template and then re-evaluates it.

It does the second evaluation in the same project folder so that items that are automatically picked up by globbing will be known as well. It then applies rules about well-known properties and items, finally producing a diff of the two states to identify the following:

  • Properties that can now be removed from the project because they are already implicitly defined by the SDK and the project had the default value
  • Properties that need to be kept in the project either because they override the default or are not defined in the SDK.
  • Items that can be removed because they are implicitly brought in by globs in the SDK
  • Items that need to be changed to the Update syntax because although they’re brought in by the SDK, there is extra metadata being added.
  • Items that need to be kept because they are are not implicit in the SDK.

This diff is used to convert a given project file.

Attribution

This tool is based on the work of Srivatsn Narayanan and his ProjectSimplifier project.

Источник

уважаемые посетители блога, если Вам понравилась, то, пожалуйста, помогите автору с лечением. Подробности тут.

По мере изучения основ C# я пробую также переписать один из моих проектов с Delphi на C#.  Пишу я пока без всяких изысков вроде визуального интерфейса, так как программа хоть и большая, но максимум, что пока от неё требуется — это собрать csv-файл из рассчитанных данных и визуализировать кое-какие моменты работы в Google Earth при помощи kml-файла. Когда я писал часть про логические операции, то мне понравилось использование выражения switch вместо одноименной конструкции — коротко,  понятно и лаконично.  Однако , эта  возможность доступна для использования только с версии  C# 8.0, а у меня приложение разрабатывалось на .NET Framework 4.7.2 и C# 7.3, соответственно. А так как кода было написано уже достаточно много, то пришлось думать над тем, как перенести моё консольное приложение с .NET Framework 4.7.2 на NET Core 3.1.

Смена версий языка C# в Visual Studio 2019 не работает

Первое, что я предпринял для того, чтобы как можно более безболезненно сменить C# 7.3 на C# 8.0 — это попробовал  изменить версию языка в Visual Studio. Судя по найденным на просторах Интернет инструкциям, делалось это через свойства проекта: надо было дважды кликнуть по Properties в обозревателе решений, затем, в открывшемся окне перейти на вкладку «Сборка», кликнуть кнопку «Дополнительно…» и, в открывшемся окне выбрать необходимую версию языка. Однако, в Visual Studio 2019 такой «фокус»не прошел:

Microsoft позаботился о том,  чтобы разместить под неактивным списком выбора версии C# пояснение того, почему на данный момент нельзя сменить версию языка. Судя по полученной информации, компилятор C# последней версии определяет версию языка по умолчанию на основе целевой платформы или платформ проекта, интерфейс смены версии C# теперь не работает, а новые функции C# 8.0 поддерживаются только на .NET Core 3.x. Так что, чтобы «пощупать» новинки в C# 8.0 пришлось искать вариант того, как быстро мигрировать с .NET Framework 4.7.2 на NET Core 3.1.

Вариант перехода с .NET Framework 4.7.2 на NET Core 3.1 нашелся относительно быстро на Хабре в блоге Microsoft (кто бы подумал), правда для консольного приложения пришлось его совсем чуточку доработать и добавить в этот вариант ещё один шаг. В конце этой статьи я приведу ссылку на первоисточник информации, чтобы соблюсти все правила цитирования.

Шаг 1. Запуск Portability Analyzer

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

Запускаем Portability Analyzer и указываем расположение исходного кода проекта:

Portability Analyzer

Portability Analyzer

После этого откроется файл Excel с отчётом по проверке. У меня этот файл выглядел следующим образом:

Portability Summary

Лист Portability Summary

Оказалось, что используемая в моем проекте сборка SharpKml не на все 100% поддерживается в .NET Standard 1.2, но для .NET Core 3.1 подходит. Значит всё хорошо, можно переходить к следующему шагу. Если бы анализатор показал меньше 100% совместимости с .NET Core 3.1, то пришлось бы искать либо другую версию SharpKml или же искать альтернативу.

Шаг 2. Миграция .csproj в SDK-стиле

В Обозревателе решений  необходимо кликнуть правой кнопкой мыши по своему проект и посмотреть есть ли в контекстном меню пункт «Изменить файл проекта». Вот так выглядит этот пункт в Visual Studio 2019:

А вот так будет выглядеть контекстное меню проекта без пункта:

Если пункт «Изменить файл проекта» имеется, то можно переходить к следующему шагу. Если же пункта нет, то делаем следующее:

  1. Смотрим, есть ли в проекта файл packages.config. В «Обозревателе решений» он выглядит вот так:

Если файл имеется, то кликаем на нем правой кнопкой мыши и выбираем пункт «Перенести packages.config в PackageReference…«:

Появится окно в котором необходимо нажать «Ok»

2. Выгружаем проект. Для этого кликаем по названию проекта правой кнопкой мыши и выбираем пункт «Выгрузить проект»

После выгрузки проект в «Обозревателе решений» будет выглядеть вот так:

Снова кликаем по названию проекта правой кнопкой мыши и выбираем пункт «Изменить название_проекта.cproj«. В моем случае этот пункт выглядел вот так:

Откроется XML-файл примерно такого содержания:

Содержимое этого файла необходимо скопировать в «Блокнот».  Теперь необходимо удалить всё из файла в Visual Studio. Согласен с автором первоисточника данной инструкции, что звучит такой пункт, мягко говоря, угрожающе. Но, на деле, ничего страшного не произойдет. Удаляйте — не переживайте (копия лежит в «Блокноте»).

Вместо только что удаленного текста вставьте следующий код необходимый для консольного приложения(здесь небольшое расхождение с первоисточником):

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp3.1</TargetFramework>
    </PropertyGroup>
</Project>

Теперь переходим в Блокнот и ищем там строку PackageReference. Если ничего не нашли — двигаемся дальше. Если нашли PackageReference, то копируем весь узел ItemGroup, содержащий PackageReference, в файл проекта, открытого в Visual Studio. Вставлять скопированный текст необходимо перед закрывающим тегом </Project>, а не в конец файла, как это было сказано в первоисточнике. Скопированный блок должен выглядеть так:

<ItemGroup>
    <PackageReference Include="SharpKml.Core">
        <Version>5.1.2</Version>
    </PackageReference>
    <PackageReference Include="System.Runtime.WindowsRuntime" Version="4.7.0" />
</ItemGroup>

У меня такой блок оказался всего один, поэтом итоговый файл *.cproj стал выглядеть вот так:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp3.1</TargetFramework>
    </PropertyGroup>
    <ItemGroup>
        <PackageReference Include="SharpKml.Core">
            <Version>5.1.2</Version>
        </PackageReference>
    </ItemGroup>
</Project>

Теперь делаем то же самое, что и выше, но только для ProjectReference. Нашли  ProjectReference — копируем весь ItemGroup в конец файла перед закрывающим тегом </Project>. У меня в Блокноте таких строк не оказалось, поэтому я перешел к следующему шагу — сохраняем все и перезагружаем проект кликнув правой кнопкой мыши по названию проекта и выбрав пункт «Перезагрузить проект». Теперь наш проект в «Обозревателе решений» стал выглядеть немного по другому:

В принципе, на этом переход с .NET Framework 4.7.2 на NET Core 3.1 закончен — можно попробовать запустить проект и убедиться, что все работает. Однако у меня при попытке запуска приложения посыпались ошибки вида:

Ошибка CS0579 Повторяющийся атрибут «System.Reflection.AssemblyCompanyAttribute» ConsoleApp3 J:CSharp SourcesMrr2017_recoveryMrr2017ConsoleApp3objDebugnetcoreapp3.1ConsoleApp3.AssemblyInfo.cs

Помогло удаление файла AssemblyInfo.cs

То, что удаление файла AssemblyInfo.cs помогло мне — не значит, что поможет вам. Если не жалко проект — можете повторить мои действия, но лучше проконсультироваться со специалистами.

После этого проект запустился, работоспособность не нарушилась. Однако встретилась другая проблема.

Использование System.Windows в .NET Core

До перехода на .NET Core для работы с координатами точек, полигонами и так далее я использовал стандартные классы Windows из пространства имен System.Windows (добавив предварительно ссылку в Зависимости). Однако, в .NET Core Visual Studio «ругнулась» на то, что в этом пространстве имен классов типа Point и Rect не существует и пометила using System.Windows  серым цветом с предложением удалить неиспользуемые директивы:

Решение нашлось на StackOverflow. Для того, чтобы использовать стандартные примитивы из Windows типа Point и Rect для приложения на .NET Core 3.x необходимо установить пакет System.Runtime.WindowsRuntimeчерез менеджер пакетов NuGet. Для этого кликаем по названию проекта правой кнопкой мыши и выбираем пункт «Управление пакетами NuGet»

В окне менеджера пакетов переходим на вкладку «Обзор» и забиваем в строку поиска System.Runtime.WindowsRuntime.

Жмем кнопку установить и ждем пока NuGet установит пакет. После установки пакета проект в «Обозревателе решений» станет выглядеть вот так:

Теперь необходимо добавить в проект пространство имен:

using Windows.Foundation;

И можно пользоваться классами Point и Rect:

Вот так простое человеческое желание использовать в работе новейшие возможности языка C# привели к переносу проекта c .NET Framework 4.7.2 на NET Core 3.1. Надеюсь, что вам эта небольшая инструкция пригодиться.

Источники информации:

  1. Статья на Хабре: Перенос десктопных приложений на .NET Core
  2. StackOverflow: Using System.Windows in .NET Core

уважаемые посетители блога, если Вам понравилась, то, пожалуйста, помогите автору с лечением. Подробности тут.

Источник

В этой статье мы рассматриваем, как перенести desktop приложение с .NET Framework на .NET Core. Мы выбрали приложение WinForms в качестве примера. Шаги для приложения WPF схожи, и мы опишем, что нужно сделать для WPF по-другому. Мы также покажем, как вы можете продолжать использовать конструктор WinForms в Visual Studio, даже если он находится в стадии разработки и еще не доступен для проектов .NET Core.

О примере:

Автор для портинга использует настольную игру Memory-style. Она юзает интерфейс WinForms (MatchingGame.exe) и библиотеку классов с игровой логикой (MatchingGame.Logic.dll), обе из которых предназначены для .NET Framework 4.5. Вы можете скачать образец здесь. Мы будем переносить проект приложения на .NET Core 3.0 и библиотеку классов на .NET Standard 2.0. Использование .NET Standard вместо .NET Core позволяет мне повторно использовать игровую логику для предоставления приложения для других платформ, таких как iOS, Android или веб.

Мы рекомендуем выполнить миграцию в отдельной ветке или если вы не используете контроль версий, создать копию своего проекта, чтобы у вас был бекап, к которому можно вернуться при необходимости. Прежде чем портировать приложение на .NET Core 3.0, нам нужно сначала подготовиться.

Подготовка к портированию:

  1. Установите .NET Core 3 и Visual Studio 2019 Preview версии (Visual Studio 2017 поддерживает только до .NET Core 2.2).
  2. Начните с рабочего решения. Убедитесь, что решение открывается, собирается и запускается без проблем.
  3. Обновите NuGet пакеты. Всегда рекомендуется использовать последние версии пакетов NuGet перед любой миграцией. Если ваше приложение ссылается на какие-либо пакеты NuGet, обновите их до последней версии. Убедитесь, что ваше приложение успешно собрано. В случае каких-либо ошибок NuGet, понизьте версию и найдите последнюю версию, которая не нарушает ваш код.
  4. Запустите анализатор портирования.NET, чтобы определить, существуют ли какие-либо API, от которых зависит ваше приложение и которые отсутствуют в .NET Core. Если таковые имеются, вам необходимо провести рефакторинг своего кода, чтобы избежать зависимостей от API, не поддерживаемых в .NET Core. Иногда можно найти альтернативный API, который обеспечивает необходимую функциональность.
  5. Замените packages.config на PackageReference. Если ваш проект использует пакеты NuGet, вам нужно добавить те же пакеты NuGet в новый проект .NET Core. Проекты .NET Core поддерживают только PackageReference для добавления пакетов NuGet. Чтобы переместить ваши ссылки NuGet из packages.config в файл проекта, в обозревателе решений щелкните правой кнопкой на packages.config -> Migrate packages.config в PackageReference.

Портирование главного проекта:

1. Создаем новое приложение того же типа (Console, WinForms, WPF, Class Library), что и приложение, которое вы готовы портировать, для .NET Core 3. Для создание проекта используем такую консольную команду: 

dotnet new winforms -o <path-to-your-solution>MatchingGame.Core

2. В файле проекта скопируйте все внешние ссылки из старого проекта, например:

<PackageReference Include="Newtonsoft.Json" Version="9.0.1" /> 1 <PackageReference Include="Newtonsoft.Json" Version="9.0.1" />

3. Build. На этом этапе, если пакеты, на которые вы ссылаетесь, поддерживают только .NET Framework, вы получите предупреждение NuGet. Если вы не обновили до последних версий пакетов NuGet на шаге 3, попробуйте найти, доступна ли последняя версия, поддерживающая .NET Core (.NET Standard), и выполните обновление. Если более новой версии нет, пакеты .NET Framework все еще можно использовать, но вы можете получить ошибки времени выполнения, если эти пакеты имеют зависимости от API, не поддерживаемых в .NET Core. Microsoft рекомендует сообщить автору пакета NuGet, что вас заинтересовало бы обновление пакета до .NET Standard. Вы можете сделать это через контактную форму в галерее NuGet.

Быстрый способ (заменить существующий файл проекта)

Первое, давайте попробуем быстрый способ портирования. Убедитесь, что у вас есть копия вашего текущего файла .csproj, возможно, вам придется использовать его в будущем. Замените ваш текущий файл .csproj файлом .csproj из проекта, который вы создали на шаге выше, и добавьте в верхнюю <PropertyGroup>:

<GenerateAssemblyInfo>false</GenerateAssemblyInfo>

Запустите build своего приложения. Если ошибок нет — поздравляю, вы успешно перенесли свой проект в .NET Core 3. Для портирования зависимого (UI) проекта см. Раздел «Портирование пользовательского интерфейса», чтобы узнать, как использовать Designer, ознакомьтесь с разделом «Использование дизайнера WinForms для проектов .NET Core». 

Медленный путь (мануальное портирование)

Если вы получили ошибки, это означает, что вам нужно внести дополнительные коррективы. Вместо быстрого способа, описанного выше. Шаги ниже также помогут лучше понять процесс миграции, поэтому, если быстрый способ сработал для вас, но вам интересно узнать все «почему», продолжайте читать :)  

1. Миграция SDK. Чтобы переместить мое приложение в .NET Core, сначала мне нужно изменить файл проекта в формате SDK, поскольку старый формат не поддерживает .NET Core. Кроме того, формат в стиле SDK намного проще и с ним легче работать. Убедитесь, что у вас есть копия вашего текущего файла .csproj. Замените содержимое файла .csproj следующим:

Для приложения WinForms:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net472</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
  </PropertyGroup>
</Project>

Для WPF приложения:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net472</TargetFramework>
    <UseWPF>true</UseWPF>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
  </PropertyGroup>
</Project>

Обратите внимание,на то что установлено <GenerateAssemblyInfo> в false. 

В проектах нового типа AssemblyInfo.cs генерируется автоматически по умолчанию. Вам нужно отключить автогенерацию или удалить файл AssemblyInfo.cs.Теперь скопируйте и вставьте все ссылки из старой версии файла .csproj в новую. Например:

NuGet package reference

<PackageReference Include="Microsoft.Windows.Compatibility" Version="2.0.1" />

Project reference

<ProjectReference Include="..MatchingGame.CoreMatchingGame.Core.csproj" />

Существует также сторонний инструмент CsprojToVs2017, который может выполнить преобразование автоматически. Но после его использования вам все равно может понадобиться удалить некоторые ссылки вручную, например:

<Reference Include="System.Data.DataSetExtensions" />
<Reference Include="Microsoft.CSharp" />
<Reference Include="System.Net.Http" />

2. Переход от .NET Framework к .NET Standard или .NET Core

После успешного преобразования библиотеки, мы можем изменить таргет для нее. В нашем случае мы хотим, чтобы библиотека классов предназначалась для .NET Standard вместо .NET Core. Таким образом, он будет доступен из любой реализации .NET. Для этого нам нужно заменить 

<TargetFramework>net472</TargetFramework>

на

<TargetFramework>netstandard2.0</TargetFramework>

Соберите свое приложение. Вы можете получить некоторые ошибки, если вы используете API, которые не включены в .NET Standard. Если вы не получили никаких ошибок с вашим приложением, вы можете пропустить следующие два шага.

3. При необходимости добавьте Windows Compatibility Pack. Некоторые API, которые не включены в .NET Standard, доступны в пакете совместимости Windows. Если вы получили ошибки на предыдущем шаге, вы можете проверить, может ли пакет Windows Compatibility Pack помочь вам в решении этих ошибок

4. Установите API Analyzer.  API Analyzer, доступный в виде пакета NuGet под названием Microsoft.DotNet.Analyzers.Compatibility, будет показывать вам предупреждения при использовании устаревших API или API, которые не поддерживаются на всех платформах (Windows, Linux, macOS). Если вы добавили Windows Compatibility Pack, я рекомендую добавить API Analyzer, чтобы отслеживать все случаи использования API, которые не будут работать на всех платформах. На этом мы заканчиваем миграцию библиотеки классов на .NET Standard. Если у вас есть несколько проектов, ссылающихся друг на друга, перенесите их «снизу вверх», начиная с проекта, который не зависит от других проектов. В примере у нас также есть проект WinForms MatchingGame.exe, поэтому теперь мы выполним аналогичные шаги для переноса. что к .NET Core.

Портирование UI

1. Добавте .NET Core UI проект. Добавляем такой проект с помощью dotnet CLI

для WinForms:

dotnet new winforms -o <path-to-your-solution>MatchingGame.Core

Для WPF проектов:

dotnet new wpf -o <path-to-your-solution>MatchingGame.Core

2. Ссылка на проекты. Сначала удалите все файлы из нового проекта (прямо сейчас он содержит общий код Hello World). Затем свяжите все файлы из существующего проекта пользовательского интерфейса .NET Framework с проектом пользовательского интерфейса .NET Core 3.0, добавив в файл .csprojfile следующую команду.

<ItemGroup>
    <Compile Include="..<Your .NET Framework Project Name>***.cs" />
    <EmbeddedResource Include="..<Your .NET Framework Project Name>***.resx" />
</ItemGroup>

Если у вас есть приложение WPF, вам также необходимо включить файлы .xaml:

<ItemGroup>
  <ApplicationDefinition Include="..WpfApp1App.xaml" Link="App.xaml">
    <Generator>MSBuild:Compile</Generator>
  </ApplicationDefinition>
  <Compile Include="..WpfApp1App.xaml.cs" Link="App.xaml.cs" />
</ItemGroup>

<ItemGroup>
  <Page Include="..WpfApp1MainWindow.xaml" Link="MainWindow.xaml">
    <Generator>MSBuild:Compile</Generator>
  </Page>
  <Compile Include="..WpfApp1MainWindow.xaml.cs" Link="MainWindow.xaml.cs" />
</ItemGroup>

3. Выравняйте пространство имен по умолчанию и имя сборки. Поскольку вы ссылаетесь на файлы, созданные дизайнером (например, Resources.Designer.cs), вы, как правило, хотите убедиться, что версия вашего приложения .NET Core использует то же пространство имен и то же имя сборки. Скопируйте следующие параметры из вашего проекта .NET Framework:

<PropertyGroup>
    <RootNamespace><!-- (Your default namespace) --></RootNamespace>
    <AssemblyName><!-- (Your assembly name) --></AssemblyName>
</PropertyGroup>

4. Отключите генерацию AssemblyInfo.cs. Как мы уже упоминали ранее, в проектах нового типа AssemblyInfo.cs генерируется автоматически по умолчанию. В то же время файл AssemblyInfo.cs из старого проекта WinForms будет скопирован и в новый проект, потому что мы связали все файлы ** *. Cs на предыдущем шаге. Это приведет к дублированию AssemblyInfo.cs. Чтобы избежать этого в файле проекта MatchingGame.Core, мы установили для GenerateAssemblyInfo значение false.

<GenerateAssemblyInfo>false</GenerateAssemblyInfo>

5. Запустите новый проект и убедитесь что все работает.

6. Скопируйте или оставьте ссылку. Теперь вместо связывания файлов вы можете скопировать их из старого проекта пользовательского интерфейса .NET Framework в новый проект пользовательского интерфейса .NET Core 3.0. После этого вы можете удалить старый проект.

Использование дизайнера WinForms для проектов .NET Core

Как мы уже упоминали выше, дизайнер WinForms для проектов .NET Core еще не доступен в Visual Studio. Однако есть два способа обойти это:

  1. Вы можете сохранять свои файлы связанными (просто не выполняя предыдущий шаг) и копировать их, пока не будет доступна поддержка дизайнера. Таким образом, вы можете изменить файлы в вашем старом проекте .NET Framework WinForms, используя конструктор. И изменения будут автоматически отражены в новом проекте .NET Core WinForms — поскольку они связаны между собой.
  2. В одном каталоге с вашим проектом WinForms может быть два файла проекта: старый файл .csproj из существующего проекта .NET Framework и новый файл .csproj в стиле SDK нового проекта .NET Core WinForms. Вам просто нужно выгрузить и перезагрузить проект с соответствующим файлом проекта в зависимости от того, хотите ли вы использовать дизайнер или нет.

Итог:

В этом посте мы рассмотрели, как перенести desktop приложение, содержащее несколько проектов, из .NET Framework в .NET Core. В типичных случаях недостаточно просто перенастроить свои проекты на .NET Core. Мы описали потенциальные проблемы, с которыми вы можете столкнуться и способы их решения. Кроме того, мы продемонстрировали, как вы все еще можете использовать дизайнер WinForms для своих портированных приложений, пока он еще не доступен для проектов .NET Core.

Источник

Источник

Понравилась статья? Поделить с друзьями:
  • Как изменить nbt теги игрока
  • Как изменить nat type
  • Как изменить nat gta 5
  • Как изменить my ini mysql
  • Как изменить mui windows 7