Posted on 31. March 2020

Подключение проекта C ++ / CLI к .NET Core

 

Одной из новых функций Visual Studio 2019 (начиная с версии 16.4) и .NET Core 3.1 является возможность создавать проекты C ++ / CLI, ориентированные на .NET Core. Это можно сделать напрямую с помощью cl.exe и link.exe (с использованием новой опции  /clr:netcore) или с помощью MSBuild (с помощью NetCore ). В этой статье я расскажу о шагах, необходимых для переноса простого проекта взаимодействия C ++ / CLI в .NET Core. Более подробную информацию можно найти в документации .NET Core.

Пример проекта

Во-первых, мне нужно сделать пример решения для миграции. Я собираюсь использовать приложение с собственной точкой входа, которая отображает форму Windows Forms через C ++ / CLI. Миграция решения с управляемой точкой входа, взаимодействующей с коренными зависимостями через C ++ / CLI, была бы такой же простой. Для начала я создал решение с тремя проектами:

1. NativeApp. Приложение C ++ для Windows из шаблона Visual Studio «Настольное приложение Windows».

1. Это будет точкой входа в приложение.

2. Я обновил его, чтобы он отображал управляемую форму (через проект CppCliInterop) и вызывал для нее метод при вызове команды IDM_ABOUT.

2. ManagedLibrary. Библиотека C # Windows Forms для .NET Core.

1. Это обеспечит форму WinForms для отображения собственного приложения.

2. Я добавил текстовое поле в форму и метод для установки текста текстового поля. Я также нацелил этот проект на .NET Core и .NET Framework, чтобы его можно было использовать с любым из них. Таким образом, мы можем сосредоточиться на переносе только части образца C ++ / CLI.

3. CppCliInterop. Библиотека .NET Framework C ++ / CLI.

1. Это будет использоваться в качестве уровня взаимодействия для подключения приложения к управляемой библиотеке WinForms.

2. Он ссылается на ManagedLibrary и позволяет коренным проектам использовать его.

3. Это проект, который необходимо перенести в .NET Core.

 

Пример кода доступен на GitHub. При запуске приложения, если вы щелкнете по меню Справка -> О программе, форма WinForms будет отображаться с текстом в текстовом поле, предоставленном проектом NativeApp.

Миграция vcxproj в .NET Core

Теперь для интересной части - обновление примера приложения для запуска на .NET Core. Необходимые изменения на самом деле минимальные. Если вы ранее переносили проекты C # в .NET Core, перенос проектов C ++ / CLI еще проще, поскольку формат файла проекта не меняется. В управляемых проектах проекты .NET Core и .NET Standard используют новый формат файла проекта в стиле SDK. Однако для проектов C ++ / CLI тот же формат vcxproj используется для таргетинга на .NET Core, как и .NET Framework.

Все, что нужно, - это внести несколько изменений в файл проекта. Некоторые из них могут быть сделаны через Visual Studio IDE, но другие (такие как добавление ссылок на WinForms) еще не могут быть. Таким образом, самый простой способ обновить файл проекта - это просто выгрузить проект в VS и отредактировать vcxproj напрямую или использовать редактор, такой как VS Code или Notepad.

1. Замените true на NetCore. Это говорит компилятору использовать /clr:netcore вместо /clr при сборке.

1. Это изменение может быть сделано через интерфейс конфигурации проекта Visual Studio, если вы предпочитаете.

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

2. Замените 4.7 на netcoreapp3.1.

1. Эти параметры можно изменить с помощью интерфейса конфигурации проекта Visual Studio на вкладке «Дополнительно». Однако обратите внимание, что изменение параметра поддержки CLR проекта, как описано в предыдущем шаге, не приведет к автоматическому изменению  , поэтому обязательно очистите параметр «.NET Target Framework Version» перед выбором .NET Core Runtime Support.

3. Замените ссылки .NET Framework (на System, System.Data, System.Windows.Forms и System.Xml) следующей ссылкой на компоненты WinForms из Windows Desktop .NET Core SDK. Этот шаг пока не поддерживает Visual Studio IDE, поэтому его необходимо выполнить, отредактировав vcxproj напрямую. Обратите внимание, что необходима только ссылка на Windows Desktop SDK, поскольку .NET Core SDK (который включает в себя такие библиотеки, как System, System.Xml и т. Д.) Включается автоматически. Существуют разные ссылки на Framework для WinForms, WPF или обоих (как описано в документах по миграции).

1.  

После внесения этих изменений проект C ++ / CLI будет успешно ориентирован на .NET Core.

Если вы используете последнюю версию Visual Studio 2019 (16.5 или 16.6 Preview 1), все должно работать и во время выполнения.

До предварительного просмотра Visual Studio 2019 16.5 2 библиотеки C ++ / CLI не создавались файл .runtimeconfig.json, необходимый для библиотек C ++ / CLI, чтобы указать, какую версию .NET Core они используют, поэтому его нужно было добавить вручную. Итак, если вы используете более старую версию Visual Studio, вам нужно будет вручную создать этот файл CppCliInterop.runtimeconfig.json и убедиться, что он скопирован в выходной каталог:

Теперь приложение может работать на .NET Core! Версия источника доступна в  the NetCore branch в репозитории GitHub. Вот форма Windows, запущенная перед загруженными модулями, показывающая выгруженный coreclr.dll.

Билд без MSBui

Миграция этого примера приложения в .NET Core была просто вопросом обновления файла проекта для целевой платформы .NET Core вместо .NET Framework. Если вам нужно собирать сборки C ++ / CLI напрямую с помощью cl.exe и link.exe. Необходимые шаги:

1. Используйте /clr:netcore вместо /clr при вызове cl.exe.

2. Справочные сборки .NET Core с использованием необходимой ссылки /FU (справочные сборки .NET Core обычно устанавливаются в папку % ProgramFiles% \ dotnet \ packs \ \ \ ref).

3. При компоновке включайте каталог хоста приложения .NET Core как LibPath. Хост-файлы приложения .NET Core обычно устанавливаются в папку % Program Files% \ dotnet \ package \ Microsoft.NETCore.App.Host.win-x64 \ \ runtime \ win-x64 \ native).

4. Убедитесь, что файл ijwhost.dll (необходимый для запуска среды выполнения .NET Core) скопирован локально из расположения узла приложения .NET Core. MSBuild делает это автоматически при сборке проекта vcxproj.

5. Создайте файл .runtimeconfig.json, как говорилось ранее.

Несколько предостережений

1. Как видите, с Visual Studio 2019 и .NET Core 3.1 направленность  на .NET Core с проектами C ++ / CLI легко. Однако есть несколько ограничений C ++ / CLI. Поддержка C ++ / CLI возможна только в Windows, даже при работе в .NET Core. Если вам нужна межплатформенная совместимость, ссылайтесь на платформу.

2. Проекты C ++ / CLI не могут быть нацелены на .NET Standard - только .NET Core или .NET Framework - и многоцелевой таргетинг не поддерживается, поэтому для создания библиотеки, которая будет использоваться как вызывающими .NET Framework, так и .NET Core, потребуются два файла проекта.

3. Если в проекте используются API, которые недоступны в .NET Core, эти вызовы необходимо будет обновить до альтернатив .NET Core. .NET Portability Analyzer может помочь найти любые зависимости Framework, которые не будут работать в .NET Core.

Подведение итогов и ресурсы

Надеемся, что в этом примере показано, как воспользоваться преимуществами новой функциональности в Visual Studio 2019 и .NET Core 3.1 для переноса проектов C ++ / CLI в .NET Core. Следующие ссылки могут быть полезны для дальнейшего чтения.

C++/CLI .NET Core migration docs

Пример, использований в этом посте (исходный пример находится в основной ветке, а обновления .NET Core - в ветви netcore)

.NET Portability Analyzer

Источник



Posted on 21. March 2020

Обновление конструктора .NET Core Windows Forms

Microsoft выпустили предварительную версию Visual Studio 16.6 - Visual Studio 2019 версии 16.6 Preview 1 и вместе с ней новую версию .NET Core конструктора Windows Forms.

 

В этом релизе представлено

Поддержка следующих элементов управления:

·      FlowLayoutPanel,

·      GroupBox,

·      ImageList,

·      MenuStrip (через PropertyBrowser и контекстное меню),

·      Panel,

·      SplitContainer,

·      Splitter,

·      TabControl,

·      TableLayoutPanel,

·      ToolStrip (через  PropertyBrowser, контекстное меню  и дизайнерские действия).

○ Локальные ресурсы и локализованные формы были включены в конструкторе.

○ Поддержка для LayoutMode и ShowGrid/SnapToGrid настроек через Tools->Options.

○ Улучшение производительности и точности.

○ Другие мелкие исправления и правки.

 

Последование

В будущих выпусках мы будем работать над User Controls поддержки сторонних контроллеров, интеграции с популярными поставщиками контролей, поддержки элементов управления данными и связанных с ними сценариев, улучшения производительности и другие функции.

 

Как пользоваться конструктором

• Вам нужно воспользоваться Visual Studio Preview channel

•Нужно включить конструктор в Visual Studio. Перейдите по  Tools > Options > Environment > Preview Features и выбрать опцию Use the preview Windows Forms designer for .NET Core apps.

 

Как сообщить о проблемах

Ваше мнение очень важно для Microsoft! Пожалуйста, сообщайте о проблемах и отправляйте запросы функций через канал обратной связи Visual Studio. Используйте значок «Отправить отзыв» в правом верхнем углу Visual Studio, как показано ниже, и укажите, что он связан с областью «WinForms .NET Core».

Источник



Posted on 18. March 2020

Анонс Entity Framework Core 5.0 Preview 1

Сегодня Microsoft объявили о первом пред просмотре EF Core 5.0.

Предпосылки

Для предварительного просмотра EF Core 5.0 требуется .NET Standard 2.1. Это означает:

• EF Core 5.0 работает на .NET Core 3.1; это не требует .NET 5.

○ Это может измениться в будущих превью в зависимости от того, как будет развиваться план для .NET 5.

EF Core 5.0 работает на других платформах, поддерживающих .NET Standard 2.1.

EF Core 5.0 не будет работать на платформах .NET Standard 2.0, включая .NET Framework.

Как скачать EF Core 5.0?

EF Core распространяется исключительно как набор пакетов NuGet. Например, чтобы добавить поставщика SQL Server в свой проект, вы можете использовать следующую команду с помощью инструмента dotnet:

dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 5.0.0-preview.2.20120.8

 

Пакеты EF Core, опубликованные сегодня:

Microsoft.EntityFrameworkCore - основной пакет EF Core

Microsoft.EntityFrameworkCore.SqlServer - поставщик базы данных для Microsoft SQL Server и SQL Azure

Microsoft.EntityFrameworkCore.Sqlite - поставщик базы данных для SQLite

Microsoft.EntityFrameworkCore.Cosmos - поставщик базы данных для Azure Cosmos DB

Microsoft.EntityFrameworkCore.InMemory - поставщик базы данных в памяти

Microsoft.EntityFrameworkCore.Tools - команды EF Core PowerShell для консоли диспетчера пакетов Visual Studio

Microsoft.EntityFrameworkCore.Design - общие компоненты времени разработки для инструментов EF Core

Microsoft.EntityFrameworkCore.SqlServer.NetTopologySuite - поддержка SQL Server для пространственных типов

Microsoft.EntityFrameworkCore.Sqlite.NetTopologySuite - поддержка SQLite для пространственных типов

Microsoft.EntityFrameworkCore.Proxies - загрузка и отслеживание изменений прокси

Microsoft.EntityFrameworkCore.Abstractions - разделенные EF Core абстракции

Microsoft.EntityFrameworkCore.Relational - общие компоненты EF Core для поставщиков реляционных баз данных

Microsoft.EntityFrameworkCore.Analyzers - анализаторы C # для EF Core

Microsoft.EntityFrameworkCore.Sqlite.Core - поставщик базы данных для SQLite без упакованного собственного двоичного файла

Мы также опубликовали версию 5.0 Preview 1 от  поставщика ADO.NET Microsoft.Data.Sqlite.Core.

Установка dotnet ef

Как и в случае EF Core 3.0 и 3.1, инструмент командной строки dotnet ef больше не включается в .NET Core SDK. Прежде чем вы сможете выполнить команды переноса EF Core или создания лесов, вам необходимо установить этот пакет как глобальный или локальный инструмент.

Чтобы установить инструмент предварительного просмотра глобально, сначала удалите любую существующую версию с помощью:

dotnet tool uninstall --global dotnet-ef

 

Затем установите с помощью:

dotnet tool install --global dotnet-ef --version 5.0.0-preview.2.20120.8

Эту новую версию dotnet ef можно использовать с проектами, в которых используются более старые версии среды выполнения EF Core.

Номера версий пакетов

В процессе сборки .NET 5 произошла ошибка, в результате которой пакеты EF preview 1 были ошибочно помечены как «5.0.0-preview.2.20120.8».

Это не должно иметь никакого функционального воздействия и не должно повлиять на Preview 2, который все еще запланирован на конец года.

Что нового в EF Core 5 Preview 1

Мы поддерживаем документацию новых функциях, представленных в каждом предварительном просмотре.

Некоторые из основных моментов из предварительного просмотра 1 вызываются ниже.

Простая регистрация

Эта опция функционально похожа на Database.Log в EF6. Таким образом, он предоставляет простой способ получения журналов из EF Core без необходимости настройки какого-либо внешнего каркаса ведения журналов.

EF Core заменяет Database.Log методом LogTo, вызываемым для DbContextOptionsBuilder в AddDbContext или OnConfiguring. Например:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder.LogTo(Console.WriteLine);

 

Существуют перегрузки для:

• Установите минимальный уровень журнала

Пример: .LogTo(Console.WriteLine, LogLevel.Information)

• Фильтр только для определенных событий

Пример: .LogTo(Console.WriteLine, new[] {CoreEventId.ContextInitialized, RelationalEventId.CommandExecuted})

• Фильтр для всех событий в определенных категориях:

Пример: .LogTo(Console.WriteLine, new[] {DbLoggerCategory.Database.Name}, LogLevel.Information)

• Используйте пользовательский фильтр по событию и уровню:

Пример: .LogTo(Console.WriteLine, (id, level) => id == RelationalEventId.CommandExecuting)

 

Формат вывода может быть минимально сконфигурирован (API постоянно меняется), но вывод по умолчанию выглядит примерно так:

warn: 12/5/2019 09:57:47.574 CoreEventId.SensitiveDataLoggingEnabledWarning[10400] (Microsoft.EntityFrameworkCore.Infrastructure)
      Sensitive data logging is enabled. Log entries and exception messages may include sensitive application data, this mode should only be enabled during development.
dbug: 12/5/2019 09:57:47.581 CoreEventId.ShadowPropertyCreated[10600] (Microsoft.EntityFrameworkCore.Model.Validation)
      The property 'BlogId' on entity type 'Post' was created in shadow state because there are no eligible CLR members with a matching name.
info: 12/5/2019 09:57:47.618 CoreEventId.ContextInitialized[10403] (Microsoft.EntityFrameworkCore.Infrastructure)
      Entity Framework Core 5.0.0-dev initialized 'BloggingContext' using provider 'Microsoft.EntityFrameworkCore.SqlServer' with options: SensitiveDataLoggingEnabled
dbug: 12/5/2019 09:57:47.644 CoreEventId.ValueGenerated[10808] (Microsoft.EntityFrameworkCore.ChangeTracking)
      'BloggingContext' generated temporary value '-2147482647' for the 'Id' property of new 'Blog' entity.
...

 

Простой способ получить сгенерированный SQL

В EF Core 5.0 представлен метод расширения ToQueryString, который будет возвращать SQL, который EF Core сгенерирует при выполнении запроса LINQ. Например, код:

var query = context.Set<customer>().Where(c => c.City == city);
Console.WriteLine(query.ToQueryString())

приводит к таким выводам при использовании поставщика базы данных SQL Server:

DECLARE p0 nvarchar(4000) = N'London';
 
SELECT [c].[CustomerID], [c].[Address], [c].[City], [c].[CompanyName], [c].[ContactName], [c].[ContactTitle], [c].[Country], [c].[Fax], [c].[Phone], [c].[PostalCode], [c].[Region]
FROM [Customers] AS [c]
WHERE [c].[City] = @__city_0

 

Обратите внимание, что объявления для параметров правильного типа также включены в вывод. Это позволяет копировать / вставлять в SQL Server Management Studio или аналогичные инструменты, так что запрос может быть выполнен для отладки / анализа.

Используйте атрибут C #, чтобы указать, что у объекта нет ключа

Тип объекта теперь можно настроить как “не имеющий ключа”, используя новый KeylessAttribute. Например:

[Keyless]
public class Address
{
    public string Street { get; set; }
    public string City { get; set; }
    public int Zip { get; set; }
}

 

Соединение или строка соединения могут быть изменены при инициализации DbContext

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

Прокси отслеживания изменений

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

Расширенные представления отладки

Представления отладки - это простой способ взглянуть на внутренности EF Core при отладке проблем. Представление отладки для Модели было реализовано. Для EF Core 5.0 мы упростили представление модели и добавили новое представление отладки для отслеживаемых объектов в диспетчере состояний.

Модель отладки

Разверните свойство Model объекта DbContext в выбранном отладчике и раскройте свойство DebugView.


LongView - это вид модели, который у нас был в течение некоторого времени. ShortView является новым и не включает аннотации моделей, которые значительно облегчают чтение. Например, вот одна из наших тестовых моделей:

Model:

  EntityType: Chassis

    Properties:

      TeamId (int) Required PK FK AfterSave:Throw

      Name (string)

      Version (no field, byte[]) Shadow Concurrency BeforeSave:Ignore AfterSave:Ignore ValueGenerated.OnAddOrUpdate

    Navigations:

      Team (_team, Team) ToPrincipal Team Inverse: Chassis PropertyAccessMode.Field

    Keys:

      TeamId PK

    Foreign keys:

      Chassis {'TeamId'} -> Team {'Id'} Unique ToDependent: Chassis ToPrincipal: Team

  EntityType: Driver

    Properties:

      Id (int) Required PK AfterSave:Throw ValueGenerated.OnAdd

      CarNumber (Nullable)

      Championships (int) Required

      Discriminator (no field, string) Shadow Required

      FastestLaps (int) Required

      Name (string)

      Podiums (int) Required

      Poles (int) Required

      Races (int) Required

      TeamId (int) Required FK Index

      Version (no field, byte[]) Shadow Concurrency BeforeSave:Ignore AfterSave:Ignore ValueGenerated.OnAddOrUpdate

      Wins (int) Required

    Navigations:

      Team (_team, Team) ToPrincipal Team Inverse: Drivers PropertyAccessMode.Field

    Keys:

      Id PK

    Foreign keys:

      Driver {'TeamId'} -> Team {'Id'} ToDependent: Drivers ToPrincipal: Team

    Indexes:

      TeamId

  EntityType: Engine

    Properties:

      Id (int) Required PK AfterSave:Throw ValueGenerated.OnAdd

      EngineSupplierId (int) Required FK Index Concurrency

      Name (string) Concurrency

    Navigations:

      EngineSupplier (_engineSupplier, EngineSupplier) ToPrincipal EngineSupplier Inverse: Engines PropertyAccessMode.Field

      Gearboxes (_gearboxes, ICollection) Collection ToDependent Gearbox PropertyAccessMode.Field

      StorageLocation (Location) ToDependent Location PropertyAccessMode.Field

      Teams (_teams, ICollection) Collection ToDependent Team Inverse: Engine PropertyAccessMode.Field

    Keys:

      Id PK

    Foreign keys:

      Engine {'EngineSupplierId'} -> EngineSupplier {'Id'} ToDependent: Engines ToPrincipal: EngineSupplier

    Indexes:

      EngineSupplierId

  EntityType: EngineSupplier

    Properties:

      Id (int) Required PK AfterSave:Throw ValueGenerated.OnAdd

      Name (string)

    Navigations:

      Engines (_engines, ICollection) Collection ToDependent Engine Inverse: EngineSupplier PropertyAccessMode.Field

    Keys:

      Id PK

  EntityType: Gearbox

    Properties:

      Id (int) Required PK AfterSave:Throw ValueGenerated.OnAdd

      EngineId (no field, Nullable) Shadow FK Index

      Name (string)

    Keys:

      Id PK

    Foreign keys:

      Gearbox {'EngineId'} -> Engine {'Id'} ToDependent: Gearboxes

    Indexes:

      EngineId

  EntityType: Location

    Properties:

      EngineId (no field, int) Shadow Required PK FK AfterSave:Throw ValueGenerated.OnAdd

      Latitude (double) Required Concurrency

      Longitude (double) Required Concurrency

    Keys:

      EngineId PK

    Foreign keys:

      Location {'EngineId'} -> Engine {'Id'} Unique Ownership ToDependent: StorageLocation

  EntityType: Sponsor

    Properties:

      Id (int) Required PK AfterSave:Throw ValueGenerated.OnAdd

      ClientToken (no field, Nullableint><int>) Shadow Concurrency

      Discriminator (no field, string) Shadow Required

      Name (string)

      Version (no field, byte[]) Shadow Concurrency BeforeSave:Ignore AfterSave:Ignore ValueGenerated.OnAddOrUpdate

    Keys:

      Id PK

  EntityType: SponsorDetails

    Properties:

      TitleSponsorId (no field, int) Shadow Required PK FK AfterSave:Throw ValueGenerated.OnAdd

      ClientToken (no field, Nullableint><int>) Shadow Concurrency

      Days (int) Required

      Space (decimal) Required

      Version (no field, byte[]) Shadow Concurrency BeforeSave:Ignore AfterSave:Ignore ValueGenerated.OnAddOrUpdate

    Keys:

      TitleSponsorId PK

    Foreign keys:

      SponsorDetails {'TitleSponsorId'} -> TitleSponsor {'Id'} Unique Ownership ToDependent: Details

  EntityType: Team

    Properties:

      Id (int) Required PK AfterSave:Throw

      Constructor (string)

      ConstructorsChampionships (int) Required

      DriversChampionships (int) Required

      EngineId (no field, Nullableint><int>) Shadow FK Index

      FastestLaps (int) Required

      GearboxId (Nullableint><int>) FK Index

      Name (string)

      Poles (int) Required

      Principal (string)

      Races (int) Required

      Tire (string)

      Version (no field, byte[]) Shadow Concurrency BeforeSave:Ignore AfterSave:Ignore ValueGenerated.OnAddOrUpdate

      Victories (int) Required

    Navigations:

      Chassis (_chassis, Chassis) ToDependent Chassis Inverse: Team PropertyAccessMode.Field

      Drivers (_drivers, ICollection) Collection ToDependent Driver Inverse: Team PropertyAccessMode.Field

      Engine (_engine, Engine) ToPrincipal Engine Inverse: Teams PropertyAccessMode.Field

      Gearbox (_gearbox, Gearbox) ToPrincipal Gearbox PropertyAccessMode.Field

    Keys:

      Id PK

    Foreign keys:

      Team {'EngineId'} -> Engine {'Id'} ToDependent: Teams ToPrincipal: Engine

      Team {'GearboxId'} -> Gearbox {'Id'} Unique ToPrincipal: Gearbox

    Indexes:

      EngineId

      GearboxId Unique

  EntityType: TestDriver Base: Driver

  EntityType: TitleSponsor Base: Sponsor

    Navigations:

      Details (_details, SponsorDetails) ToDependent SponsorDetails PropertyAccessMode.Field

 

Менеджер “debug view”

Состояние менеджера немного скрыто, чем модель. Чтобы найти его, перейдите в свойство ChangeTracker объекта DbContext в выбранном вами отладчике, а затем посмотрите в свойстве StateManager  и разверните DebugView.

Краткий обзор менеджера отображает:

• Каждый объект отслеживается

• Значение первичного ключа

• Состояние объекта: добавлено, не изменено, изменено или удалено.

• Значения свойства внешнего ключа

Например:

Engine (Shared) {Id: 1} Unchanged FK {EngineSupplierId: 1}
Location (Shared) {EngineId: 1} Unchanged FK {EngineId: 1}
Team (Shared) {Id: 4} Modified FK {EngineId: 1} FK {GearboxId: }

 

Длинный вид показывает все в коротком виде:

• Текущее значение каждого свойства

• Независимо от того, помечено ли свойство как измененное

• Исходное значение свойства, если оно отличается от текущего значения

• Сущность, на которую ссылается ссылочная навигация с использованием значения первичного ключа ссылочной сущности

• Список объектов, на которые ссылается навигация по коллекции, снова используя значения первичного ключа

Например:

Engine (Shared) {Id: 1} Unchanged
  Id: 1 PK
  EngineSupplierId: 1 FK
  Name: 'FO 108X'
  EngineSupplier: 
  Gearboxes: null><null>
  StorageLocation: {EngineId: 1}
  Teams: [{Id: 4}]
Location (Shared) {EngineId: 1} Unchanged
  EngineId: 1 PK FK
  Latitude: 47.64491
  Longitude: -122.128101
Team (Shared) {Id: 4} Modified
  Id: 4 PK
  Constructor: 'Ferrari'
  ConstructorsChampionships: 16
  DriversChampionships: 15
  EngineId: 1 FK Modified Originally 3
  FastestLaps: 221
  GearboxId: null><null> FK
  Name: 'Scuderia Ferrari Marlboro'
  Poles: 203
  Principal: 'Stefano Domenicali'
  Races: 805
  Tire: 'Bridgestone'
  Version: '0x000000000001405A'
  Victories: 212
  Chassis: null><null>
  Drivers: []
  Engine: {Id: 1}
  Gearbox: null><null>

 

Улучшена обработка нулевой семантики базы данных

Реляционные базы данных обычно обрабатывают NULL как неизвестное значение и, следовательно, не равны никаким другим NULL. C #, с другой стороны, рассматривает нулл как определенное значение, которое сравнивается с любым другим нулл. EF Core по умолчанию переводит запросы так, чтобы они использовали нулевую семантику C #. EF Core 5.0 значительно повышает эффективность этих переводов.

Свойства индексатора

EF Core 5.0 поддерживает отображение свойств индексатора C #. Это позволяет подразделениям действовать как пакеты свойств, в которых столбцы сопоставляются с именованными свойствами в пакете.

Генерация проверочных ограничений для отображений enum

Миграции EF Core 5.0 теперь могут генерировать ограничения CHECK для сопоставлений свойств перечисления. Например:

EnumColumn VARCHAR(10) NOT NULL CHECK (MyEnumColumn IN('Useful', 'Useless', 'Unknown'))

 

IsRelational

Новый метод IsRelational был добавлен в дополнение к существующим IsSqlServerIsSqlite и IsInMemory.

Это можно использовать для проверки, использует ли DbContext какой-либо поставщик реляционных баз данных. Например:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    if (Database.IsRelational())
    {
        // Do relational-specific model configuration.
    }
}

 

Советующая поддержка  Cosmos с ETags

Поставщик базы данных Azure Cosmos DB теперь поддерживает ETags. Используйте конструктор моделей в OnModelCreating для настройки ETag:

builder.Entity&lt;customer>().Property(c => c.ETag).IsEtagConcurrency();

 

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

Как запросить переводы для большего количества конструкций DateTime?

Запросы, содержащие новую конструкцию DateTime, теперь переведены.

Кроме того, теперь сопоставлены следующие функции SQL Server: * DateDiffWeek * DateFromParts

Например:

var count = context.Orders.Count(c => date > EF.Functions.DateFromParts(DateTime.Now.Year, 12, 25));

 

Перевод запросов для большего количества массива байтов

Запросы, использующие свойства Contains, Length, SequenceEqual и т. Д. В byte [], теперь переводятся в SQL. Например:

var blogs = context.Blogs.Where(e => e.Picture.Contains((byte)127)).ToList();

 

Перевод запроса для реверса

Запросы с использованием Reverse теперь переведены. Например:

context.Employees.OrderBy(e => e.EmployeeID).Reverse()

 

Запрос для битовых операторов

Запросы с использованием битовых операторов теперь транслируются в большем количестве случаев. Например:

context.Orders.Where(o => ~o.OrderID == negatedId)

 

Перевод запроса на строки в Cosmos

Запросы, использующие строковые методы Contains, StartsWith и EndsWith, теперь переводятся при использовании поставщика Azure Cosmos DB.

Ежедневные сборки

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

Как и в случае предварительного просмотра, для ежедневных сборок не требуется .NET 5; их можно использовать с GA / RTM-версией .NET Core 3.1.

Документация и отзывы

Отправной точкой для всей документации EF Core является docs.microsoft.com/ef/core/.

Пожалуйста, сообщайте о найденных проблемах и любые другие отзывы dotnet/efcore GitHub repo.

Источник



Posted on 7. November 2019

.NET Core 3 для Windows Desktop

 

Предисловие

В сентябре Microsoft выпустили .NET Core поддерживающий создание настольных приложений Windows, включая WPF и Windows Forms. Мы счастливы наблюдать, за тем как многие разработчики делятся своими историями о переносе настольных приложений (и управляющих библиотек) в .NET Core. Комания постоянно слышит истории о том, что разработчики настольных систем на платформе .NET Windows поддерживают свой бизнес с помощью WPF и Windows Forms, особенно в тех случаях, когда настольные системы превосходны, включая

- UI-dense формы над данными приложений (FOD) 

- Оперативный интерфейс пользователя

- Приложения, которые могут работать в режиме оффлайн или быть выключены

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

Это только начало разработки приложений для Windows на .NET Core. Читайте дальше, чтобы узнать больше о преимуществах .NET Core для создания приложений Windows.

 

Почему Windows Desktop на .NET Core?

.NET Core (и в будущем .NET 5, построенный на ведущих основах .NET Core) станет будущим .NET. Мы стремимся поддерживать .NET Framework долгие годы, однако он не будет получать никаких новых функций, мы их добавим только в .NET Core (в перспективе .NET 5). Чтобы улучшить стеки рабочих столов Windows и позволить разработчикам настольных компьютеров .NET получать выгоду от всех обновлений будущего, мы представили Windows Forms и WPF для .NET Core. Они по-прежнему останутся технологиями, предназначенными только для Windows, поскольку они тесно связаны с API-интерфейсами Windows. Но .NET Core, помимо кроссплатформенности, имеет множество других функций, которые могут улучшить настольные приложения.

Прежде всего, все улучшения и языковые функции будут добавлены только в .NET Core, а в будущем - в .NET 5. Хорошим примером здесь является C # 8, который стал доступен в .NET Core 3.0. Кроме того, .NET Core версии Windows Forms и WPF станут частью платформы .NET 5. Итак, перемещая   ваше приложение на .NET Core, вы готовите его к .NET 5.

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

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

- Автономное направление. Вы можете развернуть платформу .NET Core вместе со своими приложениями и стать полностью независимым от среды конечных пользователей - в вашем приложении есть все, что нужно для запуска на любом компьютере с Windows.

- Сокращение размеров приложения. В .NET Core 3 мы представили новую функцию под названием компоновщик (также иногда называемую триммером), которая будет анализировать ваш код и включать в автономное направление только те сборки из .NET Core, которые необходимы для вашего приложения. Таким образом, все детали платформы, которые не используются в вашем случае, будут обрезаны.

- Отдельные .exe файлы. Вы можете поместить свое приложение и платформу .NET Core в один файл .exe.

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

 

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

    Exe

    netcoreapp3.0

    true

    win-x64

    true

 

Различия между рабочим столом .NET Framework и рабочим столом .NET Core

При разработке настольных приложений вы не заметите большой разницы между версиями WPF и Windows Forms .NET Framework и .NET Core. Часть наших усилий заключалась в том, чтобы обеспечить функциональный паритет между этими платформами в области настольных ПК и расширить возможности .NET Core в будущем.  Приложения WPF полностью поддерживаются в .NET Core и готовы для использования, пока мы работаем над незначительными обновлениями и улучшениями. Для Windows Forms часть времени выполнения полностью перенесена в .NET Core, и команда работает над расширением Windows Forms Designer. Мы планируем подготовить его к четвертому кварталу 2020 года, пока вы можете ознакомится с предварительной версией расширения в Visual Studio 16.4 Preview 3 или более поздней версией. Не забудьте установить флажок в меню Сервис-> Параметры-> Функции предварительного просмотра-> Использовать дизайнер предварительного просмотра Windows Forms для приложений .NET Core и перезапустить Visual Studio. Пожалуйста, имейте в виду, что над ним еще ведется разработка. 

Серьезные изменения

В .NET Framework и .NET Core произошли несколько серьезных изменений, но большая часть кода, связанного с областями Windows Forms и WPF, была перенесена в Core. Если вы использовали такие компоненты, как WCF Client, Code Access Security, App Domains, Interop и Remoting, вам потребуется реорганизовать код, если вы хотите переключиться на .NET Core.

Следует помнить еще одну вещь: пути вывода по умолчанию в .NET Core отличаются от путей в .NET Framework, поэтому, если в вашем коде есть некоторые предположения относительно структуры файлов / папок запущенного приложения, то, вероятно, что он выйдет из строя во время выполнения.

Также есть изменения в настройке функций .NET. вместо файла machine.config использует файл <something>.runtimeconfig.json,который поставляется вместе с приложением и имеет ту же общую цель и аналогичную информацию. Некоторые конфигурации, такие как system.diagnostics, system.net или system.servicemodel, не поддерживаются, поэтому файл конфигурации приложения не удастся загрузить, если он содержит какой-либо из этих разделов. Это изменение касается сценариев трассировки System.Diagnostics и клиентов WCF, которые обычно настраивались с использованием конфигурации XML ранее. В .NET Core вам нужно вместо этого настроить их в коде. Чтобы изменить поведение без перекомпиляции, рассмотрите возможность настройки типов трассировки и WCF, используя значения, загруженные из источника Microsoft.Extensions.Configuration или из appSettings. 

Вы можете найти больше информации о различиях между .NET Core и .NET Framework в документации.

 

Начало работы

Проверьте эти короткие видеоуроки:

- Начало работы с WPF на .NET Core

- Начало работы с Windows Forms в .NET Core

- Различия между .NET Core и .Net Framework, что выбрать для вашего приложения

 

Перенесение приложений с .NET Framework на .NET Core

Прежде всего, запустите Portability Analyzer, если необходимо, обновите свой код, чтобы обеспечить 100% совместимость с .NET Core. Вот инструкции по использованию Portability Analyzer. Мы рекомендуем использовать элемент управления исходным кодом или сделать резервную копию вашего кода, прежде чем вносить какие-либо изменения в свое приложение, если рефакторинг не будет идти так, как вы хотите, и вы решите вернуться к своему исходному коду.

Когда ваше приложение будет полностью совместимо с .NET Core, для его переноса. В качестве отправной точки вы можете попробовать инструмент, который мы создали, чтобы помочь автоматизировать преобразование ваших проектов .NET Framework в .NET Core. - try-convert.

Важно помнить, что этот инструмент является лишь отправной точкой к .NET Core. Этот продукт не поддерживается Microsoft. Хотя он может помочь вам с некоторыми из механических аспектов миграции, он не будет обрабатывать все сценарии или типы проектов. Если в вашем решении есть проекты, которые инструмент отклоняет или не удается преобразовать, вам придется переносить их вручную. Не беспокойтесь, у нас есть много уроков о том, как это сделать (в конце этого раздела).

Инструмент - try-convert.  попытается перенести файлы проекта старого стиля в новый SDK-стиль и перенастроить соответствующие проекты в .NET Core.

 

Для ваших библиотек мы оставляем вам возможность настроить таргетинг платформы: на .NET Core или .NET Standard. Вы можете указать его в файле проекта, обновив значение для . Библиотеки без .NET Core-Specific, таких как WPF или Windows Forms, могут получить преимущество от.NET Standard:

<TargetFramework>netstandard2.1TargetFramework>

так что их могут использовать абоненты, ориентированные на множество различных платформ .NET. С другой стороны, если библиотека использует функцию, для которой требуется .NET Core (например, Windows desktop UI APIs), библиотека может ориентироваться на .NET Core:

<TargetFramework>netcoreapp3.0TargetFramework>

try-convert - это глобальный инструмент, который вы можете установить на свой компьютер, а затем запросить из CLI:

C:\> try-convert -p <path to your project>

 

или

C:\> try-convert -w <path to your solution>

 

Как упоминалось ранее, если инструмент try-convert не работает, вот материалы о том, как переносить ваше приложение вручную.

Видео

- Пример простого переноса

- Пример расширенного переноса

Документация

- Пример простого переноса

- Пример расширенного переноса (часть 1, часть 2)

- Обзор процесса переноса

 

 

Источник



Posted on 26. February 2019

.NET Core 1.0 и 1.1 перестанут работать 27 июня 2019 года

.NET Core 1.0 был выпущен 27 июня 2016 года, а .NET Core 1.1 был выпущен 16 ноября 2016 года. .NET Core 1.0 поддерживается в течение трех лет, как LTS-версия. .NET Core 1.1 входит в тот же период времени, что и .NET Core 1.0. .NET Core 1.0 и 1.1 перестанут поддерживаться 27 июня 2019 года, спустя три года после первоначального выпуска .NET Core 1.0.


С 27 июня 2019 года обновления .NET Core больше не будут включать обновленные пакеты или изображения контейнеров для .NET Core 1.0 и 1.1. Вы должны заранее запланировать обновление с .NET Core 1.x до .NET Core 2.1 или 2.2.

Обновление до .NET Core 2.1

Поддерживаемый путь обновления .NET Core 1.x приложений через .NET Core 2.1 или 2.2. Инструкции по обновлению можно найти в этих документах:
Примечание. Документация по переходу с .NET Core 2.0 на 2.1, в равной степени применима к переходу с .NET Core 1.x на 2.1.

.NET Core 2.1 является выпуском долгосрочной поддержки (LTS). Рекомендуется сделать .NET Core 2.1 Вашим новым стандартом для .NET Core разработки, особенно для приложений, которые не часто обновляются.

По состоянию на 1 октября 2018 года .NET Core 2.0 уже вышел из строя. Важно перенести приложения как минимум на .NET Core 2.1.

Политика поддержки Microsoft

У Microsoft есть политика поддержки для .NET Core. Она включает в себя политики для двух типов релизов: LTS и текущего.

.NET Core 1.0, 1.1 и 2.1 - это LTS версии. .NET Core 2.2 - это текущая версия.
  • LTS версии рассчитаны на долгосрочную поддержку. Они включали в себя функции и компоненты, которые были стабилизированы, требуя нескольких обновлений в течение более длительного срока поддержки. Эти версии являются хорошим выбором для размещения приложений, которые Вы не собираетесь обновлять.
  • Основываясь на отзывах, Текущие версии обладают новыми функциями, которые могут перенести будущие изменения. Эти версии станут хорошим выбором для приложений, которые находятся в активной разработке, и предоставят Вам доступ к последним функциям и улучшениям. Вам нужно обновиться к более новым выпускам .NET Core, чтобы оставаться в поддержке.
Оба вида выпусков получают исправления критических ошибок на протяжении всего своего жизненного цикла для обеспечения безопасности, надежности или для добавления поддержки для новых версий операционной системы. Вы должны быть в курсе последних событий, чтобы получить поддержку.

 .NET Core политика жизненного цикла поддерживаемых ОС определяет, какие версии Windows, macOS и Linux поддерживаются для каждого .NET Core выпуска.



Posted on 20. December 2018

Упаковка .NET Core приложения с помощью Desktop Bridge

Windows Desktop Bridge - это способ упаковки десктопных приложений для отправки в Microsoft Store или загрузки с любого ресурса. Это один из путей создания MSIX пакета. Вкратце: пользуйтесь им, как современным ClickOnce. Это формат упаковки с поддержкой автоматического обновления и пользователи уверены, что он не нанесет вред их системе и не загрязнит реестр.

Ранее Microsoft объявили о первых предварительных .NET Core 3 и Visual Studio 2019 версиях. Эти пробные варианты поддерживают создание графических ПК приложений с помощью .NET Core с использованием WPF и Windows Forms. Можно перенести существующее приложение из .NET Framework в .NET Core 3. Приложение, которое уже переключилось, – это NuGet Package Explorer; его открытый исходный код уже доступен на GitHub и служит отличным примером.

Если у Вас есть приложение, ориентированное на .NET Core 3, то у Вас могут возникнуть вопросы: «Как мне поделиться этим с моими пользователями?», «.NET Core 3 совершенно новый, у моих пользователей этого не будет!» «Мой IT-отдел не будет выпускать .NET Core 3 в течение года!»

Одна из действительно интересных вещей в .NET Core – это то, что он поддерживает полностью автономные приложения. То есть он не имеет внешних зависимостей. Вам не нужно ничего устанавливать, даже сам .NET Core. Вы можете скопировать вывод публикации проекта и передать его кому-нибудь для запуска. Это открывает огромные возможности, так как Вы, как разработчик, можете использовать нужные Вам фреймворки и рабочие версии, не беспокоясь о том, что помешаете другим приложениям, запущенным на компьютере, даже если рабочий вариант уже существует в box.

С полностью автономным приложением Вы сможете использовать Desktop Bridge для упаковки Вашей программы, чтобы пользователи легко могли её установить. На сегодняшний день шаблоны не поддерживают этот нестандартный сценарий, но, настроив должным образом, его можно запустить.

Вначале

Вам понадобится Visual Studio 2017 15.9 или, еще лучше, новый выпуск Visual Studio 2019 Preview. В настройках обязательно выберите рабочую нагрузку UWP для установки инструментов проекта упаковки. Загрузите .NET Core 3 Preview и создайте в нем первое WPF .NET Core приложение.

Подробно

В официальных документах описано, как добавлять проект упаковки в Ваше приложение. Microsoft советует начать с этого. В будущем, как только инструмент начнет работать, Вам будет достаточно этой информации. На данный момент, в качестве временного решения, в статье будут изложены основные принципы.

Здесь Вы можете ознакомиться с готовым продуктом. Различия, показывающие определенные изменения, здесь.

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

 

  1. Основной проект приложения, пример NetCoreDesktopBridgeApp.csproj.
  2. Проект упаковки, пример NetCoreDesktopBridgeApp.Package.wapproj.

 

Проект приложения

Начнем с основного проекта приложения, .csproj или .vbproj файла. Добавьте win-x86 к первой . Это гарантирует, что восстановление NuGet предоставит ресурсы, специфичные для среды выполнения, и поместит их в project.assets.json файл. Затем вставьте следующее:

 


  
    <_PublishItem Include="@(ResolvedFileToPublish->'%(FullPath)')" TargetPath="%(ResolvedFileToPublish.RelativePath)" OutputGroup="__GetPublishItems">
    <_PublishItem Include="$(ProjectDepsFilePath)" TargetPath="$(ProjectDepsFileName)">
    <_PublishItem Include="$(ProjectRuntimeConfigFilePath)" TargetPath="$(ProjectRuntimeConfigFileName)">
  

Полный файл проекта должен выглядеть следующим образом:

 

  


  
    WinExe
    netcoreapp3.0
    true

    
    win-x86
  

  
  
    
      <_PublishItem Include="@(ResolvedFileToPublish->'%(FullPath)')" TargetPath="%(ResolvedFileToPublish.RelativePath)" OutputGroup="__GetPublishItems">
    <_PublishItem Include="$(ProjectDepsFilePath)" TargetPath="$(ProjectDepsFileName)">
    <_PublishItem Include="$(ProjectRuntimeConfigFilePath)" TargetPath="$(ProjectRuntimeConfigFileName)">
    
  


Проект упаковки

Далее нужно добавить в (.wapproj) проект упаковки следующее, еще одно свойство:

 CoreClr

в , которая включает DefaultLanguage и EntryPointProjectUniqueName. Так Visual Studio говорит применять .NET Core отладчик. Примечание: чтобы использовать этот параметр, после установки Вам, возможно, нужно будет разгрузить / перезагрузить проект для VS. Если после изменения этого свойства система выдаст странную ошибку отладки, перезапустите VS, загрузите решение, и все должно заработать.

 

Затем найдите элемент. Если его нет, щелкните правой кнопкой мыши на Application node и добавьте ссылку на приложение в Ваш основной проект. Добавьте следующие атрибуты: SkipGetTargetFrameworkProperties = "true" Properties = "RuntimeIdentifier = win-x86; SelfContained = true". Полная ItemGroup должна выглядеть примерно так:

 


  
  

 

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

 



  @(PackageOutputGroups);__GetPublishItems

 

В этом фрагменте измените NetCoreDesktopBridgeApp\NetCoreDesktopBridgeApp.exe, чтобы он соответствовал имени и исполняемому файлу Вашего основного проекта.

Обходное решение VCRedist

В качестве контрольной точки Вам нужно указать зависимость пакета от VCRedist в Package.appxmanifest файле. Добавьте в элемент следующее:

. Когда пользователи установят Ваше приложение, Windows автоматически подтянет эту зависимость из хранилища.

 

Сборка и отладка

С указанными выше компонентами, Вы можете установить проект упаковки в качестве стартапа и выполнить отладку в обычном режиме. Он создаст программу и развернет его в локальном приложении. Выходные данные можно увидеть в bin\AnyCPU\\AppX каталоге Вашего проекта упаковки. Он должен содержать больше файлов, чем в вашем главном приложении, поскольку в нем будет автономная .NET Core среда выполнения.

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

Развертывание приложения

Существует два основных варианта развертывания пакета:

 

  1. Загрузка с помощью AppInstaller файла. Это замена ClickOnce.
  2. Microsoft Store. Пакет может быть отправлен в Store для распространения.

 

Двойная загрузка

Начиная с Windows 10 1803, загруженные приложения могут автоматически обновляться с помощью .appinstaller файла. AppInstaller является альтернативой ClickOnce для большинства сценариев. В документации описывается, как создать этот файл при публикации и поместить его в UNC-путь, общую папку или HTTPS-папку.

Если Вы загружаете контент, то нужно использовать сертификат подписи кода, которому доверяют Ваши пользователи. Для предприятия это может быть документ внутреннего центра сертификации, для общественности он должно быть получен в государственном органе. У DigiCert есть отличное предложение для сертификатов подписи кода, $ 74 / год для обычного и $ 104 / год для EV по специальной ссылке. После получения сертификата Вам необходимо обновить Package.appxmanifest, чтобы использовать его. В данной статье нет информации об автоматической подписи кода, но Вы можете ознакомиться с проектом службы подписи кода здесь.

Microsoft Store

Microsoft Store – отличный способ, чтобы Ваши пользователи узнали о приложении. Он обрабатывает подписывание кода, распространение и обновление. Более подробная информация о том, как подать приложение в Store, здесь и здесь.

 

Источник