Posted on 5. November 2023

What’s new with identity in .NET 8

Що нового в ідентифікації в .NET 8


У квітні 2023 року я писав про зобов’язання команди ASP.NET Core покращити автентифікацію, авторизацію та керування ідентифікацією в .NET 8. Представлений нами план включав три основні результати:


– Нові API для спрощення входу та керування ідентифікацією для клієнтських програм, таких як Single Page Apps (SPA) і Blazor WebAssembly.

– Увімкнення автентифікації та авторизації на основі маркерів у ASP.NET Core Identity для клієнтів, які не можуть використовувати файли cookie.

– Покращення в документації.


Усі три результати з’являтья разом із .NET 8. Крім того, ми змогли додати новий інтерфейс ідентифікації для веб-програм Blazor, який працює з обома новими режимами візуалізації, сервером і WebAssembly.


Давайте розглянемо кілька сценаріїв, уможливлених новими змінами в .NET 8. У цій публікації блогу ми розглянемо:

– Захист простого серверного веб-API

– Використання нового інтерфейсу ідентифікатора Blazor

– Додавання зовнішнього логіна, наприклад Google або Facebook

– Захист програм Blazor WebAssembly за допомогою вбудованих функцій і компонентів

– Використання токенів для клієнтів, які не можуть використовувати файли cookie


Давайте розглянемо найпростіший сценарій використання нових функцій ідентифікації.

Базовий сервер веб-API

Простий спосіб використання нової авторизації — увімкнути її в базовій програмі Web API. Цю ж програму також можна використовувати як серверну частину для Blazor WebAssembly, Angular, React та інших односторінкових веб-програм (SPA). Якщо ви починаєте з проекту ASP.NET Core Web API у .NET 8, який включає OpenAPI, ви можете додати автентифікацію за кілька кроків.


Ідентифікація є “опціональною”, тож залишилося додати ще кілька пакунків:

Microsoft.AspNetCore.Identity.EntityFrameworkCoreпакет, який забезпечує інтеграцію EF Core

– Пакет для бази даних, яку ви бажаєте використати, наприклад Microsoft.EntityFrameworkCore.SqlServer(у цьому прикладі ми використаємо базу даних у пам’яті)

 

Ви можете додати ці пакети за допомогою менеджера пакетів NuGet або командного рядка. Наприклад, щоб додати пакети за допомогою командного рядка, перейдіть до теки проєкту та виконайте такі команди dotnet:

 

Ідентифікація дозволяє налаштувати як інформацію про користувача, так і базу даних користувача, якщо у вас є вимоги, що виходять за межі того, що надається в рамках .NET Core. Для нашого базового прикладу ми просто використаємо інформацію про користувача та базу даних за замовчуванням. Для цього ми додамо новий клас до проєкту під назвою, MyUser, який успадковує від IdentityUser:

 

Додайте новий клас під назвою AppDbContext, який успадковує від IdentityDbContext:

Надання спеціального конструктора дає змогу налаштувати базу даних для різних середовищ.


Щоб налаштувати ідентифікатор для програми, відкрийте файл Program.cs. Налаштуйте ідентифікатор на використання автентифікації на основі файлів cookie та ввімкніть перевірку авторизації, додавши наступний код після виклику WebApplication.CreateBuilder(args):

 

Налаштуйте базу даних EF Core. Тут ми використаємо базу даних у пам’яті та назвемо її «AppDb». Вона використовується тут для демонстрації, тому можна легко перезапустити програму та перевірити потік, щоб зареєструватися та ввійти (кожний запуск розпочинатиметься з новою базою даних). Перехід на SQLite збереже користувачів між сеансами, але вимагає належного створення бази даних за допомогою міграцій, як показано в цьому посібнику з початку роботи з EF Core. Ви можете використовувати інші реляційні постачальники, такі як SQL Server, для свого робочого коду.

 

Налаштуйте ідентифікацію для використання бази даних EF Core та відкрийте кінцеві точки ідентифікації:

 

Позначте маршрути для кінцевих точок ідентифікації. Цей код слід розмістити після виклику builder.Build():

Тепер програма готова до автентифікації та авторизації! Щоб захистити ендпоінт, використовуйте метод розширення .RequireAuthorization(), де ви визначаєте маршрут авторизації. Якщо ви використовуєте рішення на основі контролера, ви можете додати атрибут [Authorize]до контролера або дії.

Щоб протестувати програму, запустіть її та перейдіть до інтерфейсу користувача Swagger. Розгорніть захищений ендпоінт, оберіть «випробувати» та виберіть «Виконати». Ендпоінт отримує повідомлення 404 – not found, що, мабуть, є більш безпечним, ніж повідомлення, 401 – not authorized оскільки воно не показує, що кінцева точка існує.

Swagger UI з 404

Тепер розгорніть /register і заповніть свої облікові дані. Якщо ви введете недійсну адресу електронної пошти або неправильний пароль, результат міститиме помилки перевірки.

Swagger UI з помилками перевірки

Помилки в цьому прикладі повертаються у форматі ProblemDetails , щоб ваш клієнт міг легко проаналізувати їх і за потреби відобразити помилки перевірки. Я покажу приклад цього в автономній програмі Blazor WebAssembly.


Успішна реєстрація призводить до відповіді 200 – OK. Тепер ви можете розгорнути /login та ввести ті самі облікові дані. Зауважте, що для цього прикладу є додаткові параметри, які можна видалити. Обов’язково встановіть useCookies true. Успішний вхід призводить до відповіді 200 – OK з файлом cookie в заголовку відповіді.

Тепер ви можете повторно запустити захищений ендпоінт, і він має повернути дійсний результат. Це тому, що автентифікація на основі файлів cookie надійно вбудована у ваш браузер і «просто працює». Ви щойно захистили свою першу кінцеву точку за допомогою ідентифікації!


Деякі веб-клієнти можуть не включати файли cookie в заголовок за умовчанням. Якщо ви використовуєте інструмент для тестування API, вам може знадобитися ввімкнути файли cookie в налаштуваннях. JavaScript API fetch не включає файли cookie за замовчуванням. Ви можете ввімкнути їх, встановивши значення credentials як  include в параметрах. Подібним чином, HttpClient запущений в програмі Blazor WebAssembly потребує HttpRequestMessage для включення облікових даних, наприклад:

Далі перейдемо до веб-програми Blazor.


Інтерфейс ідентифікації Blazor


Велика мета нашої команди, якої ми змогли досягти, полягала в тому, щоб реалізувати користувальницький інтерфейс ідентифікації, який включає параметри реєстрації, входу та налаштування багатофакторної автентифікації в Blazor. Інтерфейс користувача вбудовано в шаблон, коли ви вибираєте параметр «Індивідуальні облікові записи» для автентифікації. На відміну від попередньої версії інтерфейсу ідентифікації, яка була прихована, якщо ви не хотіли її налаштувати, шаблон генерує весь вихідний код, щоб ви могли змінювати його за потреби. Нова версія створена на основі компонентів Razor і працює як із серверними програмами, так і з програмами WebAssembly Blazor.

Сторінка входу Blazor

Нова веб-модель Blazor дозволяє вам налаштувати, чи інтерфейс користувача відображатиметься на стороні сервера чи клієнта, що працює в WebAssembly. Якщо ви обираєте режим WebAssembly, сервер усе одно оброблятиме всі запити на автентифікацію та авторизацію. Він також створить код для спеціальної реалізації AuthenticationStateProvider, яка відстежує стан автентифікації. Постачальник використовує  клас PersistentComponentState для попереднього відтворення стану автентифікації та збереження його на сторінці. PersistentAuthenticationStateProvider у клієнтській програмі WebAssembly використовує компонент для синхронізації стану автентифікації між сервером і браузером. Постачальник стану також може бути названий PersistingRevalidatingAuthenticationStateProvider під час роботи з автоматичною інтерактивністю або IdentityRevalidatingAuthenticationStateProvider для інтерактивності сервера.

Незважаючи на те, що приклади в цій публікації блогу зосереджені на простому сценарії входу з іменем користувача та паролем, ASP.NET Identity підтримує взаємодію на основі електронної пошти, як-от підтвердження облікового запису та відновлення пароля. Також можна налаштувати багатофакторну автентифікацію. Компоненти для всіх цих функцій включені в інтерфейс користувача.

Додайте зовнішній логін

Нам часто задають питання, як інтегрувати зовнішні входи через соціальні веб-сайти з ASP.NET Core Identity. Починаючи з проєкту веб-програми Blazor за замовчуванням, ви можете додати зовнішній логін за кілька кроків.


По-перше, вам потрібно буде зареєструвати свою програму на веб-сайті соціальної мережі. Наприклад, щоб додати логін Twitter, перейдіть на портал розробників Twitter і створіть нову програму. Вам потрібно буде надати певну базову інформацію, щоб отримати облікові дані клієнта. Після створення програми перейдіть до налаштувань програми та натисніть «редагувати» під час автентифікації. Укажіть «нативний додаток» для типу додатка, щоб потік працював правильно, і ввімкніть «запитувати електронні листи від користувачів». Вам потрібно буде надати URL-адресу зворотного виклику. У цьому прикладі ми використаємо URL-адресу зворотного виклику https://localhost:5001/signin-twitter за умовчанням для шаблону веб-програми Blazor. Ви можете просто замінити цю адресу, щоб відповідати URL-адресі вашої програми (тобто замінити 5001 своїм власним портом). Також зверніть увагу на ключ і секрет API.

Далі додайте до своєї програми відповідний пакет автентифікації. Існує список постачальників соціальної автентифікації OAuth 2.0 для ASP.NET Core, який підтримується спільнотою, із багатьма варіантами на вибір. Ви можете комбінувати кілька зовнішніх входів за потреби. Для Twitter я додам пакет AspNet.Security.OAuth.Twitter.

 

З командного рядка в кореневому каталозі проєкту сервера виконайте цю команду, щоб зберегти ключ API (ідентифікатор клієнта) і секрет.

 

Нарешті, налаштуйте вхід в Program.cs, замінивши цей код:

з цим кодом:

Файли cookie є кращим і найбезпечнішим підходом для впровадження ASP.NET Core Identity. Токени підтримуються за потреби та потребують налаштування IdentityConstants.BearerScheme. Токени є пропрієтарними, а потік на основі токенів призначений для простих сценаріїв, тому він не реалізує стандарти OAuth 2.0 або OIDC.

Що далі? Вірите чи ні, ви закінчили. Цього разу, коли ви запускаєте програму, сторінка входу автоматично визначить зовнішній логін і надасть кнопку для його використання.

Сторінка входу Blazor у Twitter

Коли ви ввійдете в систему та авторизуєтесь у програмі, вас буде перенаправлено назад і відбудеться автентифікація.

Захист програм Blazor WebAssembly

Основною мотивацією для додавання нових ідентифікаційних API було  бажання полегшити розробникам захист їхніх браузерних програм, включаючи Single Page Apps (SPA) і Blazor WebAssembly. Немає значення, чи використовуєте ви вбудований постачальник ідентифікації, спеціальну систему входу чи хмарну службу, як-от Microsoft Entra, кінцевим результатом буде ідентифікація, яка або автентифікована за допомогою претензій і ролей, або не автентифікована. У Blazor ви можете захистити компонент Razor, додавши атрибут [Authorize] до компонента або до сторінки, на якій розміщено компонент. Ви також можете захистити маршрут, додавши .RequireAuthorization()метод розширення до визначення маршруту.

Повний вихідний код для цього прикладу доступний у сховищі зразків Blazor.

Тег AuthorizeView забезпечує простий спосіб обробки вмісту, до якого користувач має доступ. Доступ до стану автентифікації можна отримати через властивість context. Зверніть увагу на наступне:

Привітання буде показано всім. У випадку Blazor WebAssembly, коли клієнту може знадобитися асинхронна автентифікація через виклики API, вміст Authorizing буде показано під час запиту та вирішення стану автентифікації. Потім, залежно від того, пройшли ви автентифікацію чи ні, ви побачите своє ім’я або повідомлення про те, що ви не автентифіковані. Як саме клієнт дізнається, чи ви автентифіковані? Ось де з’являється AuthenticationStateProvider.

Сторінка App.razor загорнута в провайдера CascadingAuthenticationState. Цей провайдер відповідає за відстеження стану автентифікації та надання до нього доступу для решти програми. AuthenticationStateProvider впроваджується в провайдера та використовується для відстеження стану. AuthenticationStateProvider також вводиться в компонент AuthorizeView. Коли стан автентифікації змінюється, постачальник сповіщає компонент AuthorizeView, і вміст оновлюється відповідно.

 

По-перше, ми хочемо переконатися, що виклики API відповідно зберігають облікові дані. Для цього я створив обробник під назвою CookieHandler.

 

В Program.cs додав обробник до HttpClient і використав фабрику клієнтів, щоб налаштувати спеціальний клієнт для автентифікації.

 

AuthUrl - це URL-адреса сервера ASP.NET Core, на якому доступні API ідентифікації. Далі я створив CookieAuthenticationStateProvider, який успадковує AuthenticationStateProvider і перевизначає метод GetAuthenticationStateAsync. Основна логіка виглядає так:

Ендпоінт інформації про користувача захищений, тому, якщо користувач не автентифікований, запит не вдасться виконати, і метод поверне неавтентифікований стан. В іншому випадку він створює відповідну ідентифікацію та заявляє та повертає автентифікований стан.


Як програма дізнається, коли стан змінився? Ось як виглядає вхід із Blazor WebAssembly за допомогою ідентифікаційного API:

Після успішного входу викликається метод NotifyAuthenticationStateChanged базового класу AuthenticationStateProvider, щоб повідомити провайдера про зміну стану. Йому передається результат запиту нового стану автентифікації, щоб він міг перевірити наявність файлу cookie. Після цього провайдер оновить компонент AuthorizeView, і користувач побачить автентифікований вміст.

Токени

У рідкісних випадках, коли ваш клієнт не підтримує файли cookie, API входу надає параметр для запиту токенів. Видається спеціальний токен (який є власністю платформи ідентифікації ASP.NET Core), який можна використовувати для автентифікації наступних запитів. Токен передається в хедері  Authorization як маркер токена. Також надається токен оновлення. Це дозволяє вашій програмі запитувати новий токен, коли закінчується термін дії старого, не змушуючи користувача знову входити в систему. Токени не є стандартними веб-токенами JSON (JWT). Це рішення було прийнято навмисно, оскільки вбудована ідентифікація призначена в основному для простих сценаріїв. Параметр маркера не призначений для повнофункціонального постачальника послуг ідентифікації або сервера маркерів, а замість цього є альтернативою параметру cookie для клієнтів, які не можуть використовувати файли cookie.

Не впевнені, чи потрібен вам сервер токенів чи ні? Прочитайте документ, який допоможе вам вибрати правильне рішення ідентифікації ASP.NET Core. Шукаєте більш просунуте рішення ідентифікації? Прочитайте наш список рішень для керування ідентифікацією для ASP.NET Core.

Документи та зразки

Третій результат – документація та зразки. Ми вже представили нову документацію та будемо додавати нові статті та зразки, коли наблизимось до релізу .NET 8. Слідкуйте за релізом № 29452 – документація та зразки для ідентифікації в .NET 8, щоб відстежувати прогрес. Будь ласка, використовуйте випуск, щоб надіслати додаткову документацію або зразки, які ви шукаєте. Ви також можете посилатися на конкретні проблеми для різних документів і залишати там свої відгуки.

Висновок

Нові функції ідентифікації в .NET 8 роблять захист ваших програм простішим, ніж будь-коли. Якщо ваші вимоги прості, тепер ви можете додати автентифікацію та авторизацію до своєї програми за допомогою кількох рядків коду. Нові API дають змогу захистити кінцеві точки веб-API за допомогою автентифікації та авторизації на основі файлів cookie. Існує також опція на основі маркерів для клієнтів, які не можуть використовувати файли cookie.


Дізнайтеся більше про нові функції ідентифікації в документації ASP.NET Core .


Source




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, здесь и здесь.

 

Источник