.NET Core 3.0 (Preview 6): Оновлення WPF та Windows Forms, Образи Alpine Docker, Покращення Event Pipe
.NET Core 3.0 (Preview 6): Оновлення WPF та Windows Forms, Образи Alpine Docker, Поліпшення Event Pipe
вийшов .NET Core 3.0 (Preview 6). До нього увійшли оновлення компіляції збірок для покращення запуску, покращення оптимізації додатків за розміром з покращеннями компонувальника та EventPipe. Ми також випустили нові образи Docker для Alpine на ARM64.
-
Нотатки випуску опубліковані в dotnet/core. Відмінності API між Preview 5 і 6 також доступні.
-
ASP.NET Core і EF Core також випущено минулого тижня.
Оновлення WPF та Windows Forms
Команда WPF повністю закінчила процес публікації більшої частини коду WPF на GitHub. Насправді вони просто опублікували вихідники п'ятнадцяти збірок. Для тих, хто знайомий з WPF, назви збірок мають бути дуже знайомі.
У деяких випадках тести все ще знаходяться в белог і повинні бути опубліковані в або до 3.0 GA. Тим не менш, наявність всього цього коду має дозволити спільноті WPF повною мірою брати участь у внесенні змін до WPF. Після прочитання деяких проблем з GitHub стає очевидним, що спільнота має власний беклог новинок, які хочеться реалізувати. Що думаєте про темну тему?
Образи Alpine Docker
Образи Docker тепер доступні як для .NET Core, так і для ASP.NET Core на ARM64. Раніше вони були доступні лише для x64.
Наступні образи можуть бути використані в Dockerfile
, або з docker pull
, як показано нижче:
docker pull mcr.microsoft.com/dotnet/core/runtime:3.0-alpine-arm64v8
docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0-alpine-arm64v8
Поліпшення Event Pipe
Event Pipe тепер підтримує мультисесійність.
Додано нові лічильники продуктивності:
- % Time in GC
- Gen 0 Heap Size
- Gen 1 Heap Size
- Gen 2 Heap Size
- LOH Heap Size
- Allocation Rate
- Number of assemblies loaded
- Number of ThreadPool Threads
- Monitor Lock Contention Rate
- ThreadPool Work Items Queue
- ThreadPool Completed Work Items Rate
Приєднання Profiler тепер реалізовано за допомогою тієї ж інфраструктури Event Pipe.
Прочитайте Гру з лічильниками від Девіда Фаулера, щоб отримати уявлення про те, що ви можете зробити за допомогою event pipe, щоб провести власне дослідження продуктивності або просто відстежувати стан програми.
Прочитайте dotnet-counters щоб встановити інструмент dotnet-counters.
Оптимізуйте свої програми .NET Core за допомогою образів ReadyToRun
Ви можете покращити час запуску програми .NET Core, скомпілювавши збірки програм у форматі ReadyToRun (R2R). R2R – це форма випереджувальної компіляції (AOT).
Бінарні файли у форматі R2R покращують продуктивність під час запуску, зменшуючи обсяг роботи, яку JIT повинен виконувати під час завантаження програми. Бінарні файли містять машинний код, аналогічний тому, що генерує JIT, що дає JIT трохи відпочинку, коли продуктивність найважливіша (при запуску). Бінарні файли в R2R форматі більше, тому що вони містять як код проміжною мовою (IL), який все ще необхідний для деяких сценаріїв, так і машинну версію того ж коду для покращення запуску.
R2R підтримується .NET Core 3.0. Його не можна використовувати з більш ранніми версіями .NET Core.
Цифри продуктивності семплів
Далі наведено цифри, що показують продуктивність семплів додатків WPF. Програма була опублікована як автономна і не використовувала компонувальник збірки (розглянуто пізніше в цій статті).
IL-only додаток:
- Час запуску: 1.9 секунд
- Використання пам'яті: 69.1 MB
- Розмір програми: 150 MB
З образами ReadyToRun:
- Час запуску: 1.3 секунди.
- Використання пам'яті: 55.7 MB
- Розмір програми: 156 MB
Докладніше про ReadyToRun образи
Ви можете скомпілювати R2R як бібліотеки, так і бінарні файли програм. В даний час бібліотеки можуть бути скомпільовані в R2R тільки як частина програми, а не для доставки у вигляді пакета NuGet. Ми хотіли б отримати більше відгуків про те, важливий чи цей сценарій.
Компіляції збірок AOT вже давно доступні як концепція для .NET, повертаючись до .NET Framework та NGEN. Ключова вада NGEN полягає в тому, що компіляція повинна виконуватися на клієнтських машинах з використанням інструменту NGEN. Неможливо згенерувати образи NGEN як частину збирання вашої програми.
Тепер .NET Core. Він приходить із crossgen, який виробляє машинні образи в новому форматі ReadyToRun. Назва описує його основну цінність, що полягає в тому, що ці машинні образи можуть бути створені як частина вашої збірки і готові до запуску без будь-якої додаткової роботи на клієнтських машинах. Це серйозне покращення, а також важлива перемога у боротьбі зі зміною клімату.
З точки зору сумісності образи ReadyToRun аналогічні збіркам IL з деякими ключовими відмінностями.
- IL збірки містять тільки IL код. Вони можуть працювати в будь-якому середовищі виконання, яке підтримує цільову інфраструктуру для цієї збірки. Наприклад,
netstandard2.0
збірка може працювати на .NET Framework 4.6+ і .NET Core 2.0+, на будь-якій підтримуваній операційній системі (Windows, macOS, Linux) та архітектурі (Intel, ARM, 32-розрядна , 64-розрядна). - Складання R2R містять IL і власний код. Вони скомпільовані для певної мінімальної версії середовища виконання .NET Core та оточення середовища виконання (RID). наприклад, збірка
netstandard2.0
може бути R2R-скомпільована для .NET Core 3.0 та Linux x64. Вона буде використовуватися лише в цій або сумісній конфігурації (наприклад, .NET Core 3.1 або .NET Core 5.0 у Linux x64), оскільки вона містить власний код, який можна використовувати лише в цьому середовищі виконання.
Інструкції
ReadyToRun компіляція доступна лише для публікації. Прев'ю-версію було випущено в .NET Core 3.0 (Preview 5).
Щоб увімкнути компіляцію ReadyToRun, вам потрібно:
- Встановити значення властивості
PublishReadyToRun
якtrue
. - Опублікувати за допомогою точного
RuntimeIdentifier
.
Примітка. Коли складання програми компілюється, створюваний власний код залежить від платформи та архітектури (тому при публікації необхідно вказувати дійсний RuntimeIdentifier).
Примітка: ReadyToRun зараз підтримується лише для автономних програм. Він буде доданий для залежних від фреймворку додатків в пізнішому анонсі.
Машинну генерацію символів можна увімкнути, встановивши для властивості PublishReadyToRunEmitSymbols
значення true
 . Вам не потрібно створювати машинні символи для налагодження. Ці символи корисні лише для цілей профілювання.
В даний час SDK підтримує спосіб виключення певних збірок з компілювання образи ReadyToRun. Це може бути корисно в тих випадках, коли збирання не потребують оптимізації для підвищення продуктивності. Виключення збірок у цьому випадку допоможе зменшити розмір програми. Якщо компілятору ReadyToRun не вдається скомпілювати певну збірку, рішенням також може бути її виключення.
Виняток виконується за допомогою групи елементів PublishReadyToRunExclude:
Кросплатформні/архітектурні компіляції
Компілятор ReadyToRun поки не підтримує крос-націлення. Потрібно компілювати за заданою метою. Наприклад, якщо вам потрібні образи R2R для Windows x64, вам потрібно виконати команду публікації у цьому середовищі.
Винятки:
- Windows x64 може бути використана для компіляції образів Windows ARM32, ARM64 та x86.
- Windows x86 може бути використана для компіляції образів Windows ARM32.
- Linux x64 можна використовувати для компіляції образів Linux ARM32 and ARM64.
Компонування збірок
NET core 3.0 SDK поставляється з інструментом, який може зменшити розмір додатків шляхом аналізу IL і виключення зборів, що не використовуються.
З .NET Core завжди можна було публікувати автономні програми, які включають все необхідне для запуску вашого коду, без необхідності встановлювати .NET на мету розгортання. У деяких випадках для роботи програми потрібно лише невелике підмножина фреймворку, і його можна було б зробити значно меншим за рахунок включення лише використовуваних бібліотек.
Ми використовуємо компонувальник IL для сканування IL вашої програми, щоб визначити, який код насправді потрібен, а потім виключити бібліотеки фреймворків, що не використовуються. Це може значно зменшити розмір деяких програм. Як правило, невеликі консольні програми, подібні до інструментів, отримують найбільшу вигоду, оскільки вони часто використовують невеликі підмножини фреймворку і зазвичай добре піддаються обрізанню.
Щоб використовувати цей інструмент, встановіть PublishTrimmed=true
у своєму проекті та опублікуйте автономну програму:
Вихідні дані публікації будуть включати підмножину бібліотек інфраструктури, залежно від того, що викликає код програми. Для програми helloworld компонувальник зменшує розмір з ~68 МБ до ~28 МБ.
Програми або фреймворки (включаючи ASP.NET Core та WPF), в яких використовуються рефлексія або пов'язані динамічні функції, часто ламаються при обрізанні, оскільки компонувальник не знає про цю динамічну поведінку і зазвичай не може визначити, які типи фреймворків потрібні для рефлексії під час виконання. Щоб обрізати такі програми, ви повинні повідомити компонувальника про будь-які типи, необхідні для рефлексії у вашому коді та в будь-яких пакетах або середовищах, від яких ви залежите. Обов'язково протестуйте свої програми після обрізки.
Для отримання додаткової інформації про IL Linker див. документацію або відвідайте репозиторій mono/linker.
Примітка: У попередніх версіях .NET Core, ILLink.Tasks постачався як зовнішній пакет NuGet і надавав більшу частину тієї ж функціональності. Він більше не підтримується - оновіть до останньої версії 3.0 SDK.
Спільне використання компонувальника Linker та ReadToRun
Компоновщик Linker та компілятор ReadyToRun можуть використовуватися для однієї й тієї ж програми. В цілому, компонувальник робить ваш додаток меншим, а потім готовий до запуску компілятор знову зробить його трохи більше, але зі значним виграшем у продуктивності. Варто протестувати різні конфігурації, щоб зрозуміти вплив кожного варіанта.
Примітка: dotnet/sdk #3257 запобігає спільному використанню компонувальника та ReadyToRun для програм WPF та Windows Forms. Ми працюємо над виправленням цього у рамках випуску .NET Core 3.0.
Семпл нативного хостингу
Нещодавно було опубліковано Native Hosting sample. Він демонструє найкращий підхід для хостингу .NET Core у нативному додатку.
У рамках .NET Core 3.0 ми тепер надаємо загальні функціональні можливості власним хостингам .NET Core, які раніше були доступні тільки для керованих додатків .NET Core через офіційно надані хостинги .NET Core. Функціональність насамперед пов'язана із завантаженням складання. Ця функціональність має спростити створення власних хостингів, які можуть використовувати повний набір функцій .NET Core.
Підтримка HTTP/2 у HttpClient
HTTP/2 є основною версією протоколу HTTP. Деякі з особливостей HTTP/2 - підтримка стиснення хедера і повністю мультиплексовані потоки по одному з'єднанню. Хоча HTTP/2 зберігає семантику HTTP (хедери HTTP, методи тощо), він відрізняється від HTTP/1.x тим, як дані надсилаються.
HttpClient
тепер підтримує виконання запитів HTTP/2. За замовчуванням залишається HTTP/1.1, але ви можете відмовитися від на користь HTTP/2, встановивши версію за допомогою HTTP-запиту.
В якості альтернативи ви можете за промовчанням надсилати запити HTTP/2, встановивши DefaultRequestVersion
в HttpClient
.
Внаслідок цього зміни сервери та клієнти повинні узгодити версію протоколу, що використовується. ALPN (Application-Layer Protocol Negotiation) — це розширення TLS, яке дозволяє серверу та клієнту узгоджувати версію протоколу, що використовується в рамках їхньої взаємодії. Однак варто врахувати, що більшість серверів підтримують лише ALPN як єдиний спосіб встановити з'єднання HTTP/2. Таким чином, HTTP/2 узгоджується HttpClient
тільки по з'єднанню TLS.
У сценаріях розробки, коли сервер і клієнт апріорі знають, що обидва будуть говорити на HTTP/2 без шифрування, ви можете встановити з'єднання HTTP/2 через cleartext, встановивши перемикач AppContext
або змінне середовище. (DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1
).