Нові можливості WPF у .NET 7

Спільнота WPF наповнена багатьма ентузіастами з дійсно дивовижним досвідом, і ця публікація має на меті висвітлити те, що було зроблено в репозиторії dotnet/wpf за останні кілька місяців. Щира подяка учасникам, які постійно працюють над покращенням WPF. Ось короткий огляд того, що було зроблено за останні кілька місяців у репозиторії dotnet/wpf.

Продуктивність

WPF в .NET 7 містить низку покращень, які не обмежуються лише непотрібними упакуваннями (boxing) та розпакуваннями (unboxing), використанням Span для маніпуляцій з рядками, кращим розподілом/перерозподілом об’єктів, покращенням пам’яті, рендерингом шрифтів і т.д., а й очищенням коду та звільненням місця для майбутньої роботи.

Упакування (boxing) / розпакування (unboxing)

Процеси boxing та unboxing вимагають значних обчислювальних затрат. Коли тип значення є упакованим, необхідно виділити та створити новий об’єкт. Незначною мірою, перетворення, необхідне для розпакування, також вимагає значних обчислювальних витрат.

Уникнення boxing при встановленні властивостей DependencyObject 

Припинення boxing WeakReferenceListEnumerator у використанні PresentationSource

Повторне використання об’єктів типу bool в UncommonField.SetValue

Зупинення boxing у Visual.SetDpiScaleVisualFlags

Уникайте boxing enumerator у XamlSchemaContext.UpdateNamespaceByUriList

Уникнення boxing enumerator списків/масивів у CreateTextLSRuns

Уникнення boxing enumerator списків у XamlObjectWriter.Logic_ConvertPositionalParamsToArgs

Розподіл

Чим більше об’єктів розміщено на купі, тим більше накладних витрат на відновлення цих об’єктів після завершення їхнього життєвого циклу. Зменшення кількості таких розподілів у пам’яті зменшує накладні витрати на GC.

Уникнення розподілів, пов’язаних з Hashtable, в AccessorTable

Уникнення розподілів, пов’язаних з Hashtable в DataBindEngine

Видалення розподілу закриття/делегування у ItemContainerGenerator

Уникнення виділення делегату для виклику ListCollectionView.PrepareComparer

Уникнення зайвого виділення byte[] у Baml2006Reader.Process_Header

Уникнення виділення Stack лише для того, щоб поглянути на нього

Припинення виділення непотрібного StringBuilders у ParsePropertyComments

Уникнення непотрібного перерозподілу StringBuilder у LookupAndSetLocalizabilityAttribute

Уникнення виняткового виділення рядків у StaticExtension.ProvideValue

Видалення непотрібного виділення рядків та рядків[] з MS.Internal.ContentType

Видалення деяких непотрібних StringBuilders

Видалення виділення підрядків з Baml2006Reader.Logic_GetFullXmlns

Не призначайте резервне ім’я в XamlNamespace.GetXamlType, якщо воно не потрібне

Уникнення зайвих розподілів перелічувачів у XamlDirective.GetHashCode

Різне

Уникнення надмірних викликів гетера індексу PropertyValues.

Зміцнення випадків відповідно до умов перегонів 

Усунення копіювання пам’яті під час читання даних шрифтів 

Невелике покращення продуктивності PathParser

Використання зрізу проміжку замість підрядка в AbbreviatedGeometryParser.ReadNumber

Уникнення непотрібного дублювання полів у NullableBooleanBox’ах

Змінення більшості не генетичних видів на генетичні

Деякі покращення в FrugalList

Уникнення зайвого Collection в обгортці CombineSources

Уникнення зайвого List<> (Список<>) в GetTextRunSpans

Доступність

З метою забезпечення доступності елементів керування WPF, нижче наведено вдосконалення продуктів, які були реалізовані у WPF.

1. WPF DataGrid/GridView ширину стовпчика можна змінити за допомогою комбінації клавіш ALT+стрілка вліво або вправо — Ширина стовпчика Datagrid може бути змінена за допомогою комбінації клавіш Alt + стрілка вліво / стрілка вправо.

2. Сортувати стовпець таблиці даних за допомогою клавіші F3 - Стовпці таблиці даних тепер можна сортувати (якщо для стовпця увімкнено сортування) за допомогою комбінації клавіш F3.

3. Голос диктора для пунктів меню, які можна перевірити — екранні диктори можуть коректно повідомляти про наявність пунктів меню, які можна перевірити.

Виправлення помилок

Хоча WPF залишається повністю підтримуваним і обслуговуваним на .NET Framework, більшість виправлень і всі нові функції будуть перенесені тільки в .NET Core, де є можливість вносити більші зміни. Спільнота допомогла усунути деякі застарілі помилки в цьому випуску.

FocusVisualStyle не можна перезаписати глобально 

CommandParameter робить недійсним CanExecute за допомогою miloush 

Проблеми з підказками

.NET 6 Зміна поведінки підказок у порівнянні з .NET 5 (помилка?)

Помилка підказки комбінованого елемента

ContextMenu перестає працювати, якщо його власника видалено з візуального дерева

Виправлено помилку округлення під час серіалізації glyphrun

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

Модернізація інфраструктури

Однією з основних сфер для покращення, озвучених громадою, є рівень, за яким приймаються внески від громади. За допомогою наведених нижче модернізацій інфраструктури планується вплинути на рівень, за яким ми приймаємо внески від громади

Microsoft объявляет о следующем обновлении Windows Community Toolkit версии 6.0, которое стало возможным, благодаря помощи и вкладу нашего сообщества разработчиков. В этом выпуске реализована поддержка ARM64 для инструментария, а также обновление XAML Islands для поддержки .NET Core 3. Кроме того, у нас есть новые функции, такие как элемент управления “Eye Dropper ” и новые помощники уведомлений Win32. У нас также есть обновление Microsoft Graph благодаря XAML контролам.

Смотрите более подробную информацию об этих функциях ниже.

XAML Islands приближает UWP к WPF, WinForms и Win32

XAML  Islands позволяет разработчику улучшить внешний вид и функциональность существующего приложения Win32 для WPF, Windows Forms или C ++, использовать новейшие функции пользовательского интерфейса Windows 10, которые доступны только через UWP контроллы, например, рукописный ввод:

В этой версии усовершенствована поддержка инструментов для .NET Core 3, что делает ее еще проще для того чтобы начать.

Документация для XAML Islands.

Поддержка ARM64

Windows Community Toolkit теперь поддерживает приложения, которые ориентированные на ARM64. Что позволяет разработчикам использовать преимущества времени автономной работы и производительности, работая на собственной архитектуре для таких устройств, как Surface Pro X. Разработчики также тесно сотрудничали с командой Win2D, чтобы убедиться, что она поддерживает ARM64. Это было важно для Lottie и других функций инструментария, основанных на Win2D.

Улучшенная анимация Lottie

Обновление предоставляет больше возможностей Adobe After Effects для Lottie-Windows, в том числе Linear и Radial Gradients, Masks, Track Mattes поддержку codegen для Image Layers . Мы надеемся, что эти дополнения позволят дизайнерам и разработчикам приложений создавать еще более привлекательные визуальные интерфейсы для пользователей Windows 10. Поскольку некоторые из этих функций основаны на более новых SDK, Lottie-Windows теперь также предлагает адаптивное управление версиями. Мы рассчитываем на то, что сообщество определит приоритеты работы с функциями, поэтому, пожалуйста, продолжайте оставлять свои ценные отзывы и предложения для Lottie-Windows!

“Eye Dropper “

Новый элемент управления “Eye Dropper” позволяет вам легко и быстро выбирать цвет приложения.

Документация для EyeDropper.

Превью XAML Graph Controls

Новое дополнение к Windows Community Toolkit позволяет разработчикам легко проходить проверку подлинности и получать доступ к Microsoft Graph в приложениях Windows 10 для создания обширных данных. Эти элементы управления доступны в качестве предварительного просмотра версии 6.1 и будут работать с приложениями UWP и в приложениях WPF / WinForms для Win32 через XAML Islands в .NET Core 3. Кроме того, совсем скоро с помощью Xamarin и Uno Platform у вас появится возможность использовать их на Android и iOS.

Читайте об этих новых элементах управления в нашем официальном заявлении или на GitHub.

Начни сегодня

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

Напоминаем, что вы можете начать работу, следуя нашему учебному пособию docs.microsoft.com tutorial, или просмотреть последние функции, установив образец приложения Windows Community Toolkit из Магазина Microsoft. Если вы хотите внести свой вклад в разработку, пожалуйста, присоединяйтесь на GitHub! Чтобы присоединиться к беседе в Twitter, используйте хештег #WindowsToolkit.

Всем удачного кодирования!

Источник

На конференции Microsoft Build было объявлено, что Windows 10 May 2019 Update (версия 1903) будет включать XAML Islands v1.

Ниже Вы можете ознакомиться с более подробной информацией плана выпуска и двух рабочих направлений в процессе разработки: .NET обертки и поддержка Visual Studio 2019.

Что такое XAML Islands?

XAML Islands позволяют .NET и нативным Win32 приложениям размещать элементы управления UWP XAML. Вы можете расширить возможности и функциональность Ваших существующих десктопных приложений с помощью последних инноваций пользовательского интерфейса, ранее доступных только для UWP приложений. Например, Вы можете использовать такие элементы управления, как ColorPicker, InkCanvas, CalendarView и NavigationView, в Ваших существующих C ++ Win32, Windows Forms и WPF приложениях.

С XAML Islands Вы можете модернизировать Ваше приложение в собственном стиле без необходимости переписывать его заново – просто используйте элементы управления UWP XAML.

Как использовать XAML Islands?

Первый компонент – API  UWP XAML хостинг. Это набор API Windows 10 (Windows Runtime классы и COM интерфейсы), которые поставляются на Windows 10 в версии 1903. Если у Вас есть нативное C ++ Win32 приложение, использующее Common Controls библиотеку (Comctl32.dll) или MFC, и Вам необходимо модернизировать Ваш интерфейс, смело используйте эти API.

Второй компонент состоит из обернутых .NET элементов управления и элементов управления хоста. Это набор оберток API  UWP XAML хостинга в Windows Community Toolkit как для Windows Forms, так и для WPF разработчиков.

Каковы требования для использования XAML Islands в Ваших приложениях?

• Windows 10 версии 1903 и выше: Независимо от того, есть ли у Вас Win32 или .NET приложение, текущая версия XAML Islands работает только с приложениями для Windows 10 версии 1903 и выше.
• Windows 10 SDK версия 1903 (10.0.18362): этот SDK содержит заголовки, библиотеки, метаданные и инструменты для сборки Windows 10 приложений, используя XAML Islands.
• Упакованное десктопное приложение: Десктопные приложения можно упаковать в MSIX для доступа к определенным Windows 10 API, таким как живые тайлы и уведомления. Для упаковки Вашего приложения необходимо использовать Windows Application Packaging Project. Упаковка Вашего приложения не означает, что оно будет работать в изолированной программной среде с ограниченными UWP привилегиями. Вместо этого Ваше упакованное Win32 приложение будет работать в режиме полного доверия. Упакованные с XAML Islands приложения будут оптимизированы для разработчиков, которые работают с Visual Studio 2019.

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

• Visual Studio 2019: только Visual Studio 2019 будет иметь набор инструментов, необходимый для сборки десктопных приложений с использованием XAML Islands.
• .NET Core 3.0: эта среда полностью поддерживается для .NET приложений. Некоторые сценарии также будут работать в приложениях, предназначенных для .NET Framework 4.7.2, но для этих приложений существуют некоторые ограничения, например использование управляемых сторонних элементов управления.

• Если сторонний WinRT компонент является нативным (написан на C ++ / WinRT), пользовательский элемент управления может использоваться как .NET Framework 4.7.2, так и как NET Core 3.
• Если сторонний WinRT компонент является управляемым (например, написан на C#), пользовательский элемент управления может использоваться только на .NET Core 3. Полная версия .NET Framework не полностью поддерживается в этом сценарии, и она требует некоторой кросс-компиляции для того, чтобы работать на всех.

Таблица поддержки платформы для XAML Islands в1:

Если Ваше приложение нацелено на .NET Core 3, независимо от того, является ли сторонний WinRT компонент, который Вы размещаете, нативным или управляемым, Вы получите оптимизированный опыт работы. Если Ваше приложение нацелено на полную .NET Framework версию, Вы получите оптимизированный опыт, только если Ваш сторонний WinRT компонент является нативным.

Как использовать XAML Islands в Вашем нативном C ++ Win32 приложении?

Если Вы C ++ разработчик, Вам нужно использовать API UWP XAML хостинга. Вот одни из основных шагов:

• Сначала инициализируется UWP XAML структура в текущем потоке (Вы можете использовать статический InitializeForCurrentThread метод для WindowsXamlManager класса).
• Создайте DesktopWindowXamlSource объект, который требует HWND от Вашего приложения. DesktopWindowXamlSource создаст ChildWindow, где Вы сможете разместить XAML контент.
• Вам нужно позаботиться о фокусировке клавиатуры, когда пользователи переходят на XAML Islands и выходят из них. Этот DesktopWindowXamlSource объект предоставляет событие для распределения фокусировки клавиатуры.

Вы можете ознакомиться с более подробной информацией здесь: https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the-xaml-hosting-api

Как использовать XAML Islands в Вашем .NET приложении?

Windows Community Toolkit версии 6.0.0 (на данный момент в preview-версии) предоставляет несколько NuGet пакетов для Windows Forms и WPF, которые Вы можете добавить в Ваш проект.

Элемент управления WindowXamlHost является хост-элементом, в котором можно размещать все типы UWP XAML контента.

Обернутые элементы управления создаются для работы с большинством событий и свойств небольшого набора определенных UWP элементов в WPF и Windows Forms элементы. В настоящее время предоставляются следующие упакованные элементы управления:

• InkCanvas оборачивает UWP InkCanvas и InkToolbar и предоставляет поверхность и панели инструментов для взаимодействия с Ink пользователем.
• MediaPlayerElement позволяет Вашим .NET приложениям использовать современные аудио- и видео-кодеки и предоставляет более высокую производительность для потоковой передачи и воспроизведения медиа контента.
• MapControl позволяет использовать в Ваших приложениях последние инновации картографической платформы, например, больше фотореалистичных карт.
• SwapChainPanel (preview-версия) позволяет добавлять DirectX 12 контент в Ваше приложение.

Какие современные веб элементы доступны для десктопных приложений?

Windows Forms и WPF приложения используют элемент управления WebBrowser, который использует рендеринг Internet Explorer и поэтому не поддерживает HTML5 и другие функции. Windows Community Toolkit содержит Windows Forms и WPF обертки для UWP WebView элемента, который использует Edge в качестве инструмента рендеринга, поэтому эти приложения могут размещать веб-контент, который требуюется на HTML5.

Windows Community Toolkit также содержит элемент управления WebViewCompatible. Этот элемент использует либо WebBrowser, либо WebView рендеринг, в зависимости от Windows версии, на которой работает приложение:

• Приложения для Windows 10 версии 1803 и выше будут использовать текущий инструмент WebView рендеринга.
• Приложения для более ранних Windows версий, таких как Windows 8.1, будут использовать более старый инструмент WebBrowser рендеринга.

Используют ли XAML Islands другой поток?

Нет. XAML Islands работают в том же потоке пользовательского интерфейса Вашего десктопного приложения. Вы можете сразу получить доступ ко всем UWP XAML объектам из Вашего кода. Это отличается от Windows Forms и WPF технологий.

Есть ли инструкции?

XAML Islands Lab предоставляет пошаговые инструкции по использованию обернутых элементов управления и хост-элементов в Windows Community Toolkit для добавления UWP элементов управления в уже существующее WPF приложение. Эта работа включает в себя полный код для WPF приложения, а также подробные инструкции для каждого этапа.

Этот C ++ Win32 образец демонстрирует полную реализацию размещения пользовательского UWP элемента управления в неупакованном C ++ Win32 приложении (то есть приложении, которое не встроено в MSIX пакет).

Для WPF .NET Core 3 приложения, которое использует UWP проект в User Control, Вы можете использовать следующее:

• https://aka.ms/xamlislandssamples 

Windows Community Toolkit содержит демонстрационные версии для проверки обернутого элемента управления и хост-элемента.

• https://github.com/windows-toolkit/Microsoft.Toolkit.Win32

Каков план выпуска XAML Islands в1?

1. Windows 10 May 2019 Update содержит первый выпуск XAML Islands (в1).

2. Windows Community Toolkit, версии 6.0, будет содержать WindowsXamlHost и упакованные элементы управления для .NET Framework.

• Это запланировано на лето 2019 года.
• Будет preview-версия 6.1, которая будет содержать WindowsXamlHost .NET Core 3 версию и упакованные элементы управления. Это обновление будет выпущено вместе с .NET Core 3 – во второй половине 2019 года.

3. Visual Studio 2019 обновится во второй половине 2019 года вместе с .NET Core 3, который будет поддерживать XAML Islands в1. Помните, что только с упакованными приложениями Вы получите оптимизированный опыт работы.

Каков план выпуска XAML Islands в2?

XAML Islands в2 будет поставляться в составе WinUI 3.0. Следовательно, вторая версия будет поддерживать те же Windows 10 версии, что и WinUI 3.0. Основной выпуск WinUI v3 запланирован на первую половину 2020 года. WinUI – это проект с открытым исходным кодом, и Вы можете следить за последними событиями здесь: https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md 

Где оставить отзыв о XAML Islands?

• Основной канал – GitHub: https://github.com/microsoft/microsoft-ui-XAML
• Вы также можете написать на XAML Islands Feedback@microsoft.com
• Или твитнуть на странице @windowsui
• Если у Вас возникнут трудности с .NET обертками, Вы также можете связаться со службой поддержки по адресу https://github.com/windows-toolkit/Microsoft.Toolkit.Win32

Ольга Гавриш недавно написала пост о том, как перенести WinForms приложение с .NET Framework на .NET Core. В этом блог посте будут выполняться шаги по переносу WPF-приложения на .NET Core 3. Многие из этих шагов будут знакомы Вам из поста Ольги, но здесь добавлены некоторые дополнительные общие зависимости, с которыми пользователи могут столкнуться, например, использование WCF  клиента или сторонних пакетов пользовательского интерфейса.

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

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

Видео инструкции

Если предпочитаете видео инструкции по перемещению приложения, Вы можете просмотреть ролики на YouTube, посвященный переносу приложения.

О примере

Для этого примера было написано простое приложение для торговли товарами под названием «Bean Trader». У пользователей приложения есть учетные записи с разным количеством бобов (которые бывают четырех разных цветов). С этим приложением, пользователи могут предлагать и принимать сделки с другими пользователями. Приложение не очень большое (около 2000 строк кода), но, с точки зрения сложности, на шаг впереди «Hello World». Оно создано для того, чтобы Вы могли видеть некоторые проблемы, с которыми пользователи могут столкнуться при переносе реальных приложений.

Интересные зависимости в приложении:

• Соединение WCF с бэкенд-трейдингом через двойной NetTcp канал
• Моделирование пользовательского интерфейса и MahApps.Metro диалогов
• Внедрение зависимостей с помощью Castle.Windsor (хотя, многие DI-решения, включая Microsoft.Extensions.DependencyInjection, могут использоваться в этом сценарии)
• Настройки приложения в app.config и реестре
• Различные ресурсы и resx файлы

Исходный код этого приложения доступен на GitHub. Исходный источник (до переноса) доступен в NetFx\BeanTraderClient каталоге. Последнее перемещенное приложение находится в NetCore\BeanTraderClient директории. Бэкэнд-сервис, с которым должно соединяться приложение, доступен в BeanTraderServer папке.

Отказ

Помните, что этот образец приложения создан для демонстрации проблем перемещения на .NET Core и их решений. Он не предназначен для демонстрации лучших WPF возможностей. На самом деле, некоторые анти-паттерны были намеренно добавлены в приложение для воспроизведения некоторых проблем при перемещении.

Обзор процесса перемещения

Процесс перехода с .NET Framework на .NET Core состоит из четырех основных этапов.

1. Во-первых, полезно подготовиться к перемещению, разобраться в зависимостях проекта и перемещать проект в легко переносимом состоянии.

1. Используйте такие инструменты, как .NET Portability Analyzer, для изучения .NET Framework зависимостей.
2. Также стоит обновить NuGet ссылки для использования формата и, возможно, придется обновить версии NuGet пакетов.

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

3. В-третьих, исходному коду могут потребоваться некоторые обновления, основанные на различных API, как в .NET Core, так и в .NET Core версиях необходимых NuGet пакетов. Это обычно самый продолжительный этап.

4. В-четвертых, не забудьте протестировать перенесенное приложение! Некоторые .NET Core/.NET Framework различия не проявляются до времени выполнения (хотя существуют Roslyn анализаторы кода, помогающие идентифицировать эти случаи).

Шаг 1: Подготовка

Образец клонирован и готов к работе? Супер, теперь можно начать!

Основная проблема при перемещение .NET Framework приложения на .NET Core заключается в том, что его зависимости в .NET Core могут работать по-разному (или вообще не работать!). Сейчас перемещение стало намного проще, чем раньше – многие NuGet пакеты теперь нацелены на .NET Standard, и, начиная с .NET Core 2.0, .NET Framework и .NET Core стали довольно похожими. Тем не менее, некоторые различия остаются (как в поддержке NuGet пакетов, так и в доступных .NET API).

Обновление NuGet ссылок к

Старые .NET Framework проекты обычно перечисляют свои NuGet зависимости в packages.config файле. Однако новый формат файла проекта в SDK стиле по-разному ссылается на NuGet пакеты. Для ссылки на NuGet зависимости он использует элементы в самом csproj файле (а не в отдельном файле конфигурации). К счастью, csproj файлы старого стиля также могут использовать современный синтаксис.

При перемещении есть два преимущества использования ссылок в стиле:

1. Это стиль NuGet ссылки, который потребуется для нового файла .NET Core проекта. Если Вы уже используете , эти элементы файла проекта можно скопировать и вставить непосредственно в новый проект.
2. В отличие от packages.config файла, элементы ссылаются только на самые важные зависимости, от которых напрямую зависит Ваш проект. Все остальные переходные NuGet пакеты будут определены во время восстановления и записаны в автоматически сгенерированный obj\project.assets.json файл. Это значительно упрощает рассуждение о том, какие зависимости есть у Вашего проекта, что полезно при определении того, будут ли необходимые зависимости работать на .NET Core или нет.

Итак, первый шаг к перемещению Bean Trader образца – это подготовить его к использованию NuGet ссылок. С Visual Studio это очень легко. Просто щелкните правой кнопкой мыши по packages.config файлу проекта в Visual Studio Solution Explorer и выберите «Перенести packages.config в PackageReference».

Появится диалоговое окно, показывающее вычисленные самые важные NuGet зависимости и спрашивающее, какие другие NuGet  пакеты должны быть перемещены к этому уровню. Ни один из этих других пакетов не должен быть высокого уровня для Bean Trader образца, поэтому Вы можете снять все эти флажки. Затем нажмите «ОК», и packages.config файл будет удален, а элементы будут добавлены в файл проекта.

Ссылки в стиле не хранят NuGet пакеты локально в папке «пакетов» (вместо этого они хранятся глобально, в качестве оптимизации), поэтому после перемещения Вам нужно будет отредактировать csproj файл и удалить элементы, относящиеся к FxCop анализаторам, которые ранее были из .. \packages директории.

Просмотрите NuGet пакеты

Теперь, когда можно увидеть NuGet пакеты верхнего уровня, от которых зависит проект, есть возможность проверить, будут ли эти пакеты доступны в .NET Core или нет.

Вы можете узнать, поддерживается ли .NET Core пакет, взглянув на его зависимости от nuget.org. Сайт fuget.org, созданный сообществом, также отображает эту информацию в верхней информационной части страницы пакета.

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

В случае примера Bean Trader есть следующие NuGet  зависимости:

• Castle.Windsor, версия 4.1.1. Этот пакет предназначен для .NET Standard 1.6, поэтому он будет работать на .NET Core.
• Microsoft.CodeAnalysis.FxCopAnalyzers, версия 2.6.3. Это метапакет, поэтому неясно, какие платформы он поддерживает, но в документации указано, что его новейшая версия (2.9.2) будет работать как для .NET Framework, так и для .NET Core.
• Nito.AsyncEx, версия 4.0.1. Этот пакет не предназначен для .NET Core, но более новая версия 5.0 сможет это сделать. Это часто происходит при миграции, потому что многие NuGet пакеты за последний год добавили поддержку .NET Standard, но более старые проекты будут использовать более старые версии этих пакетов. Если разница версий незначительна, ее можно легко обновить до более новой версии. Поскольку это серьезное изменение версии, Вы должны быть осторожны при обновлении, поскольку в пакете могут произойти критические изменения.
• MahApps.Metro, версия 1.6.5. Этот пакет также не предназначен для .NET Core, но имеет более новую preview-версию (2.0-alpha).

Все NuGet зависимости из примера Bean Trader предназначены либо для .NET Standard/.NET Core, либо для их более новых версий, поэтому у Вас вряд ли возникнут какие-либо проблемы с блокировкой.

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

• Есть ли другие похожие пакеты, которые можно использовать вместо этих? Иногда NuGet авторы публикуют отдельные .Core версии библиотек, специально предназначенные для .NET Core. Пакеты Enterprise Library – пример того, как сообщество публикует альтернативы с .NetCore расширением.
• Если альтернатив нет, Вы можете продолжить использование пакетов, нацеленных на .NET Framework, имея в виду, что Вам потребуется тщательно их протестировать после запуска на .NET Core.

Обновите NuGet пакеты

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

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

В случае примера Bean Trader все необходимые обновления могут быть легко выполнены (с помощью диспетчера NuGet пакетов в Visual Studio) с одним исключением: обновление с MahApps.Metro 1.6.5 до 2.0 выявляет серьезные изменения, связанные с API-интерфейсами для управления темами и акцентами.

В идеале приложение должно быть обновлено, чтобы использовать более новую версию пакета (так как оно, скорее всего, будет работать на .NET Core). Однако в некоторых случаях это может быть неосуществимо. В этом случае MahApps.Metro не будет обновляться, потому что этот туториал сосредоточен на переходе на .NET Core 3, а не на MahApps.Metro 2. Кроме того, это .NET Framework зависимость с низким уровнем риска, поскольку приложение Bean Trader выполняет только небольшую часть MahApps.Metro. Конечно, после завершения миграции потребуется тестирование, чтобы убедиться, что все работает.

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

Анализ переносимости .NET Framework

Теперь рассмотрим зависимости .NET Framework API. Инструмент .NET Portability Analyzer полезен для понимания того, какие из .NET API, которые использует Ваш проект, доступны на других .NET платформах.

Этот инструмент поставляется в виде Visual Studio плагина, инструмента командной строки или в виде простого графического интерфейса пользователя, который упрощает его параметры и всегда сообщает о совместимости с .NET Core 3.

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

1. Загрузите API Portability Analyzer.

2. Убедитесь, что приложение .NET Framework для переноса собралось успешно.

3. Запустите API-порт с помощью командной строки, например:

1. ApiPort.exe analyze -f -r html -r excel -t “.NET Core”
2. Аргумент -f указывает путь, содержащий двоичные файлы для анализа. Аргумент -r указывает, какой формат выходного файла Вам нужен. Будут полезны как HTML, так и Excel форматы. Аргумент -t указывает, с какой .NET платформой будет анализироваться использование API. В данном случае нужен .NET Core, поскольку именно эта платформа является целевой.  Так как версия не указана, по умолчанию для API Port используется последняя версия платформы (в данном случае – .NET Core 3.0).

Когда Вы откроете HTML-отчет, в первом разделе будут перечислены все проанализированные двоичные файлы и какой процент используемых им .NET API доступен на целевой платформе. Сам по себе этот процент не очень значимый. Что более полезно, так это увидеть конкретные API, которые отсутствуют. Для этого щелкните имя сборки или прокрутите вниз до отчетов по отдельным сборкам.

Вам нужно беспокоиться только о тех сборках, для которых у Вас есть исходный код. В отчете Bean Trader ApiPort перечислено много двоичных файлов, но большинство из них относится к NuGet пакетам. Например, Castle.Windsor показывает, что он зависит от некоторых System.Web API интерфейсов, отсутствующих в .NET Core. Это не проблема, потому что Castle.Windsor поддерживает .NET Core. Обычно NuGet пакеты имеют разные двоичные файлы для использования на разных  .NET платформах, поэтому независимо от того, использует ли .NET Framework версия Castle.Windsor System.Web API-интерфейсы или нет, это не имеет значения, если пакет также предназначен для .NET Standard или. NET Core.

В случае примера Bean Trader единственный двоичный файл, который нужно изучить – BeanTraderClient, и в отчете показано, что отсутствуют только два .NET API – System.ServiceModel.ClientBase.Close и System.ServiceModel.ClientBase.Open

Это вряд ли избавит от проблем, потому что WCF Client API (в основном) поддерживаются в .NET Core, поэтому для этих центральных API должны быть альтернативы. Фактически, глядя на System.ServiceModel .NET Core (используя https://apisof.net), можно увидеть, что в .NET Core есть асинхронные альтернативы.

Исходя из этого отчета и предыдущего анализа NuGet зависимостей, похоже, что не должно быть серьезных проблем при переносе образца Bean Trader в .NET Core. Следующий шаг для начала переноса.

Шаг 2: Перемещение файла проекта

Поскольку .NET Core использует новый формат файла проекта в SDK стиле, существующий csproj файл не будет работать. Нам понадобится новый файл проекта для .NET Core версии приложения Bean Trader. Если Вам не нужно было собирать .NET Framework версию приложения в будущем, Вы могли бы просто заменить существующий csproj файл. Но часто разработчики хотят создавать обе версии – особенно тогда, когда .NET Core 3 все еще находится в режиме предварительного просмотра.

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

1. Вы можете использовать многоцелевой таргетинг (указав несколько целей), чтобы получить один файл проекта, который создаст .NET Core и .NET Framework версии решения. В будущем это, вероятно, будет лучшим вариантом. Однако, на данный момент, некоторые функции плохо работают с многоцелевым таргетингом. Поэтому сейчас рекомендуется иметь отдельные файлы проекта для версий приложений, ориентированных на .NET Core и .NET Framework.
2. Вы можете поместить новый файл проекта в другую директорию. Это облегчит разделение сборки, но означает, что Вы не сможете использовать преимущества новой системы проектов, позволяющей автоматически добавлять C# и XAML файлы. Также необходимо будет добавить элементы для XAML ресурсов, чтобы они были встроены с правильными путями.
3. Вы можете поместить новый файл проекта в ту же директорию, что и текущий файл проекта. Это позволяет избежать проблем, связанных с предыдущим параметром, но приведет к конфликту obj и bin папок для двух проектов. Если Вы одновременно открываете только один из проектов, это не будет проблемой. Но если они оба будут открыты одновременно, Вам нужно будет обновить проекты, чтобы использовать разные пути вывода и промежуточные пути вывода.

Лучший вариант – пункт 3 (чтобы файлы проекта работали бок о бок), поэтому этот подход будет использоваться в качестве примера.

Для создания нового файла проекта, обычно используется команда dotnet new wpf во временном каталоге, чтобы сгенерировать файл проекта, а затем скопировать / переименовать его в нужное место. Существует также созданный сообществом инструмент CsprojToVs2017, который может автоматизировать некоторые процессы миграции. Этот инструмент полезен, но все еще нуждается в улучшении, чтобы  все детали миграции были верны. Одна конкретная область, которую инструмент не обрабатывает до конца, – это миграция NuGet пакетов из packages.config файлов. Если инструмент запускается в файле проекта, который все еще использует файл packages.config для ссылки на NuGet пакеты, он автоматически мигрирует в элементы, но добавит элементы для всех пакетов, а не только для верхнего уровня. Однако если Вы уже перешли на элементы с помощью Visual Studio, то этот инструмент может помочь с остальной частью конвертирования. Перенос вручную даст лучшие результаты, если у Вас только несколько проектов. Но если Вы портируете десятки или сотни файлов проекта, то такой инструмент, как CsprojToVs2017, может Вам помочь.

Так что, запустите dotnet new wpf во временном каталоге и переместите созданный csproj файл в BeanTraderClient папку и переименуйте его в BeanTraderClient.Core.csproj.

Поскольку новый формат файла проекта автоматически включает C#, resx и XAML файлы, которые он находит в своей директории, файл проекта уже почти готов! Чтобы завершить миграцию, одновременно откройте старые и новые файлы проекта и просмотрите старый, чтобы увидеть, нужно ли переносить какую-либо информацию, содержащуюся в нем. В этом случае следующие элементы должны быть скопированы в новый проект:

• , и свойства должны быть скопированы.
• Также нужно добавить false свойство в новый файл проекта, поскольку образец Bean Trader включает атрибуты уровня сборки в файле AssemblyInfo.cs (например, [AssemblyTitle]). По умолчанию новые проекты в SDK стиле автоматически генерируют эти атрибуты на основе свойств в csproj файле. Поскольку в этом случае это не нужно (автоматически сгенерированные атрибуты будут конфликтовать с теми что из AssemblyInfo.cs), Вам нужно отключить автоматически сгенерированные атрибуты с помощью .
• Хотя resx файлы автоматически добавляются в качестве встроенных ресурсов, другие элементы, например изображения, не добавляются. Итак, скопируйте элементы для того, чтобы вставить изображения и значки файлов. Вы можете упростить png ссылки на одну строку, используя поддержку нового формата файла проекта для сокращения шаблонов: .
• Аналогично, элементы будут включены автоматически, но по умолчанию они не будут скопированы в директорию выхода. Поскольку проект Bean Trader включает в себя элемент, который копируется в директорию выхода (с использованием PreserveNewest), необходимо обновить автоматически заполненный элемент для этого файла, например:
• Образец Bean Trader содержит XAML файл (Default.Accent.xaml) в качестве Содержимого (а не Страницы), поскольку темы и акценты, определенные в этом файле, загружаются из XAML файла во время выполнения, а не встраиваются в само приложение. Новая система проекта автоматически содержит этот файл в виде <Страницы>, разумеется, поскольку это XAML файл. Итак, нужно удалить как XAML файл, так и страницу () и добавить его в качестве содержимого:
• Наконец, добавьте NuGet ссылки, скопировав со всеми элементами. Если бы ранее NuGet пакеты не обновлялись до версий, совместимых с .NET Core, Вы могли бы сделать это сейчас, когда ссылки на пакеты находятся в специфичном для .NET Core проекте.

На этом этапе должна появиться возможность добавить новый проект в решение BeanTrader и открыть его в Visual Studio. Проект должен выглядеть правильно в Solution Explorer и dotnet restore BeanTraderClient.Core.csproj должен успешно восстановить пакеты (с двумя ожидаемыми предупреждениями, связанными с MahApps.Metro версией, которая используется для нацеливания на .NET Framework).

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

Источник

Visual Studio 2017 15.4 представил новый проект Windows Application Packaging, который поможет Вам модернизировать Ваше приложение с помощью нового стека развертывания Windows 10 приложений (Windows 10 App Deployment Stack).

Microsoft рассказывали об этом в предыдущей статье: Visual Studio 2017 Update 4 упрощает модернизацию Вашего приложения и делает его готовым к публикации, и сегодня Microsoft представит Вам новые возможности Visual Studio 2017 15.5, которые позволяют создавать новые сценарии для проекта упаковки Windows приложений с использованием всех преимуществ Windows 10 функций в Ваших приложениях.

В этой статье будут рассматриватся три примера, которые подчеркнут новые возможности, добавленные в проект упаковки, чтобы обеспечить упаковку не только для Win32 приложений, но и для приложений и UWP компонентов:

1. Фоновое выполнение с использованием фоновых задач UWP.
2. Интеграция Windows Shell с использованием соглашения о совместном использовании.
3. Добавление инвестиций Win32 кода в пакеты UWP приложений.

Первые два примера это уже существующие WPF приложения, упакованные как APPX с расширенным функционалом, который реализован как UWP компоненты. Первое приложение добавляет фоновое исполнение на основе фоновых UWP задач, а второе приложение показывает, как активно внедрять приложение с Windows 10 оболочкой, используя функцию в виде соглашения о совместном использовании (Share contracts). В заключение, последнее приложение – это точка входа в UWP, вызывающая классический Win32 процесс, который взаимодействует с Excel.

Обратите внимание: Поскольку UWP компоненты необходимо скомпилировать для определенной платформы: x86 или x64, конфигурация любого конфигурационного решения для любого процессора не будет работать ни в одном из этих образцов.

Все образцы доступны в отчетах на GitHub, разделе Windows-Packaging-Samples. Для этих образцов требуется Visual Studio 2017 15.5 Preview 4 или выше, доступный для загрузки с https://www.visualstudio.com/downloads.

1. WPF с Фоновыми Задачами

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

Чтобы показать, как использовать эту функцию в Ваших Win32 приложениях, Microsoft собирается реализовать небольшую утилиту, которая сделает HTTP-запрос к URL-адресу, настроенному пользователем, и покажет прошедшие миллисекунды в всплывающих уведомлениях (Toast Notification).

Microsoft создадаст WPF приложение, чтобы пользователь мог указывать URL-адрес для проверки и включения / выключения фоновых задач. Фоновая задача будет реализована как Windows Runtime Component (WINMD). Чтобы включить этот компонент в пакет, нужно создать UWP приложение, которое использует этот компонент, и, наконец, добавить WPF и UWP проекты в качестве ссылок на проект упаковки. Ниже приведен список необходимых шагов.

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

1. Упакуйте Ваше настольное приложение, используя проект упаковки
2. Добавьте Runtime Windows компонент для выполнения фоновой задачи
3. Добавьте UWP приложение, которое ссылается на компонент времени выполнения
4. Добавить ссылку на UWP приложение из проекта упаковки
5. Настройте Фоновую задачу в манифесте
6. Зарегистрируйте фоновую задачу из Настольного приложения

После завершения 1-4 шагов, у Вас должно быть решение для проектов, как показано на рисунке ниже:

Проект упаковки ссылается не только на WPF приложение, но и на UWP проект. По этой причине решение должно быть настроено для конкретной платформы, поскольку UWP недоступен для любых конфигураций ЦП.

Реализация Фоновых Задач

Фоновая задача – это класс C#, который реализует интерфейс IBackgroundTask. Этот интерфейс определяет Run метод, который будет вызываться, когда система запустит задачу.

public sealed class SiteVerifier : IBackgroundTask
{
    public async void Run(IBackgroundTaskInstance taskInstance)
    {
 
        taskInstance.Canceled += TaskInstance_Canceled;
        BackgroundTaskDeferral deferral = taskInstance.GetDeferral();
        var msg = await MeasureRequestTime();
        ShowToast(msg);
        deferral.Complete();
    }
 
    private async Task MeasureRequestTime()
    {
        string msg;
        try
        {
            var url = ApplicationData.Current.LocalSettings.Values["UrlToVerify"] as string;
            var http = new HttpClient();
            Stopwatch clock = Stopwatch.StartNew();
            var response = await http.GetAsync(new Uri(url));
            response.EnsureSuccessStatusCode();
            var elapsed = clock.ElapsedMilliseconds;
            clock.Stop();
            msg = $"{url} took {elapsed.ToString()} ms";
        }
        catch (Exception ex)
        {
            msg = ex.Message;
        }
        return msg;
}

Обратите внимание, как используется LocalSettings в ApplicationData для обмена информацией между WPF приложением и фоновой UWP задачей.

Для настройки фоновой задачи Вам необходимо обновить манифест, используя конструктор манифеста. Перейдите на вкладку деклараций, добавьте фоновую задачу и настройте точку входа как реализацию.

Для регистрации фоновой задачи в системе, Вам нужно вызвать Windows 10 API из WPF приложения. Этот API доступен в Windows 10 SDK, и для его использования с .NET необходимо добавить ссылки, объясненные здесь. После того, как Вы получили доступ к Windows 10 API, Вы можете использовать класс BackgroundTaskRegistration для настройки фоновой задачи, как показано в приведенном ниже коде:

public void RegisterBackgroundTask(String triggerName)
{
    var current = BackgroundTaskRegistration.AllTasks
        .Where(b => b.Value.Name == triggerName).FirstOrDefault().Value;
 
    if (current is null)
    {
        BackgroundTaskBuilder builder = new BackgroundTaskBuilder();
        builder.Name = triggerName;
        builder.SetTrigger(new MaintenanceTrigger(15, false));
        builder.TaskEntryPoint = "HttpPing.SiteVerifier";
        builder.Register();
        System.Diagnostics.Debug.WriteLine("BGTask registered:" + triggerName);
    }
    else
    {
        System.Diagnostics.Debug.WriteLine("Task already:" + triggerName);
    }
}

Для регистрирации фоновой задачи, убедитесь, что задача не была зарегистрирована ранее, а затем используйте BackgroundTaskBuilder для настройки имени и Триггера, в этом случае используется MainteinanceTrigger.

2. Зарегистрируйте Ваше приложение в качестве Share Target

Совместные контракты - это Windows 10 функция, которая позволяет осуществлять обмен информацией между двумя приложениями, отправителем и получателем. Благодаря Desktop Bridge, Вы можете зарегистрировать UWP приложение в качестве общего получателя, а затем интегрировать с Win32 приложением. После регистрации приложения, оно будет отображаться каждый раз, когда пользователь вызывает функцию совместного использования, как показано ниже:

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

Пакет должен обозначить цель о совместном использовании (Share Target), включая имя UWP приложения:

При активации, приложение получает информацию о целевом ресурсе из параметра ShareOperation. Ниже приведен пример фрагмента кода:

protected async override void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
    operation = (ShareOperation)e.Parameter;
    if (operation.Data.Contains(StandardDataFormats.StorageItems))
    {
        var items = await operation.Data.GetStorageItemsAsync();
        file = items[0] as StorageFile;
        IRandomAccessStreamWithContentType stream = await file.OpenReadAsync();
 
        await this.Dispatcher.RunAsync(CoreDispatcherPriority.Normal, async () =>
        {
            BitmapImage image = new BitmapImage();
            this.img.Source = image;
            await image.SetSourceAsync(stream);
        });
    }
}

Теперь каждый раз, когда пользователь делится изображением и выбирает данное приложение, запускается Share UI приложение и затем отображается UWP-интерфейс.

После нажатия кнопки «Поделиться в WPF приложение», UWP вызывает обработчик событий и копирует изображение в папку ApplicationData, и затем запускает Win32 приложение с помощью FullTrustProcessLauncher.

private async void ShareBtn_Click(object sender, RoutedEventArgs e)
{
    await file.CopyAsync(ApplicationData.Current.LocalFolder);
    operation.ReportCompleted();
    await FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();
}

Для использования FullTrustProcessLauncher, применяется Desktop расширение для UWP, это расширение доступно в виде SDK ссылки, которая доступна в диалоговом окне UWP приложения «Add References»:

И, наконец, зарегистрируйте настольное расширение и целевой выполняемый файл в манифесте:

<... >

3. Добавьте Office взаимодействие из UWP приложения

Одной из ключевых особенностей Desktop Bridge является возможность добавлять исполняемые Win32 файлы в Ваш пакет приложений и запускать их как цельный процесс из UWP приложения. Теперь, с проектом Windows Application Packaging, Вы можете создавать пакеты, содержащие двоичные UWP, так и Win32 файлы.

Дополнительно к диспетчеру процессов, есть расширение App Service, которое поможет Вам установить канал связи между Вашим UWP приложением и Win32 процессом.

В этом примере показан способ добавления Win32 процесса (приложение командной строки) для управления Excel листом с использованием офисного взаимодействия.

Microsoft начинает с UWP приложения, которое использует сетку данных Telerik для отображения некоторых табличных данных, также будет добавлена  кнопка для экспорта одних и тех же данных в Excel, как показано ниже:

Исследователь решений этого примера очень похож на предыдущий пример с тремя проектами в решении: UWP приложение, командная Win32 строка и проект упаковки со ссылкой на оба проекта. Тем не менее, обратите внимание, что в этом случае точкой входа приложения (выделенной жирным шрифтом) является UWP проект:

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

Для открытия канала связи в Win32 процессе, добавьте ссылку на Windows API, как описано здесь:

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

Connection = new AppServiceConnection();
connection.AppServiceName = "ExcelInteropService";
connection.PackageFamilyName = Windows.ApplicationModel.Package.Current.Id.FamilyName;
connection.RequestReceived += Connection_RequestReceived;
connection.ServiceClosed += Connection_ServiceClosed;

Заключая данную статью

Новые функции, добавленные в проект упаковки в Visual Studio 2017, помогут Вам модернизировать существующие настольные приложения для получения максимального результата от UWP и Win32 в одном пакете. Этот новый проект поможет Вам настроить Ваш пакет с помощью конструктора манифеста, отладить Ваше приложение в контексте Desktop Bridge и, наконец, поможет подготовить пакеты для отправки в Microsoft Store или на другие ресурсы. Для получения дополнительной информации изучите:

• Desktop Bridge Документы
• Desktop Bridge Образцы
• Образцы проекта Windows Application Packaging
• Видео по Модернизации Приложения на канале Channel 9

Команда разработчиков проекта Prism опубликовала CTP 4-й версии. Изменения этой версии касаются модульности и MVVM. А именно:

• библиотека Prism для Windows Presentation Foundation и Silverlight;
• QuickStarts:
  • новые и обновленные QuickStarts в Prism 4.0:
    • базовый MVVM QuickStart;
    • MVVM QuickStart;
    • QuickStart модульности (обновлен для использования MEF так же как и Unity);
  • адаптированные QuickStart из Prism 2.0;
    • QuickStarts по командам:
    • агрегатор событий QuickStarts;
    • Hello Worl QuickStarts;
    • QuickStarts по использованию проекта в нескольких технологиях:
    • QuckStarts по компоновке пользовательского интерфейса
  • RI адаптирован с Prism 2.0

Кроме MVVM QuickStarts остальные примеры имеют по два решения для настольных приложения и для Silverlight приложений.

Lester в своем блоге опубликовал описание как настроить Xaml FXCop правила в FXCop GUI.

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

1. Установиться FXCop.

2. Обновить FxCop.exe.config (находится в %ProgramFiles(x86)%\ Microsoft FxCop 1.36) для запуска на .Net 4.0.

Добавить ниже приведенный xml в нижнюю часть файла конфигурации после тега

3. Открыть FxCop.exe (находится в %ProgramFiles(x86)%\ Microsoft FxCop 1.36).

4. Загрузить сборку с правилами FxCop (если у вас не собственной с правилами, то можете использовать Microsoft.Xaml.Tools.FxCop.dll).

5. Загрузить Targets\сборку проекта.

6. На этом настройка завершена. Нажмите кнопку Analyze и вы увидите результаты работы установленных правил.

Michael S. Scherotter анонсировал обновление Microsoft Silverlight Analytics Framework (я писал о нем раньше). Возможности этого обнолвения:

• поддержка Windows Phone 7;
• поддержка Microsoft Silverlight Media Framework 2.0;
• поддержка Webtrends для Silverlight 4, WPF и Windows Phone 7;
• добавлена поддержка Google Analytics для WPF и Windows Phone 7;
• исправлен ряд ошибок.

Поддержка Windows Phone 7

Добавлено поведение TrackLocation для Windows Phone 7, которое позволяет отслеживать перемещение пользователя. При этом (по-хорошему) необходимо запрашивать разрешение у пользователя.

Silverlight Media Framework Player или Smooth Streaming Client пока что не доступны для Windows Phone 7. Но когда они появятся для этой платформы, то буду и состветствующие поведения для них.

Microsoft Silverlight Media Framework 2.0

Полностью поддерживается возможность отслеживания действий пользователя при использовании Microsoft Silverlight Media Framework 2.0.

Поддержка Webtrends

Разработчики продукта добавили поведение WebtrendsAnalytics для Silverlight 4, WPF и Windows Phone 7. Оно разработано с использованием Webtrends Data Collection API.

Добавлена поддержка Google Analytics в WPF и Windows Phone 7

Разработчики сделали несколько улучшений Google Analytics компонента для поддержки WPF и Windows Phone 7. Было исправлено несколько ошибок, которые нашли пользователи.

Вышло небольшое обновление Prism 4.0. Содержание этой версии:

• QuickStart (Находится в каталоге QuickStar);
  • Model-View-ViewModel - для этого решения необходим установленый Silverlight;
  • Использование модульности через MEF - WPF и Silverlight версии. Использует .Net Framework 4.0;
  • Использование модульности через Unity - WPF и Silverlight версии. Некоторые функции аналогичны решению с MEF, но используют Unity с контейнером DI.
• Hot to решения: простой MVVM - простые решения с использованием MVVM паттерна;
• Stock Trader решение
• Документация

Руководство по WPF и Silverlight предназначено помочь разработчикам более легко создавать приложения уровня предприятия с использованием технологий Windows Presentation Foundation (WPF) и Silverlight, включая приложения, которые могут быть ориентированы на WPF и Silverlight одновременно. Это руководство поможет спроектировать и построить гибкие клиентские приложения - приложения, которые используют слабо связанные, независимо расширяемые части, которые работают вместе в рамках общего решения.

На основании отзывов разработчиков, это руководство будет развиваться дальше.

Это небольшое обновление включает в себя:

• Все проекты обновились для работы в Visual Studio 2010
• Настольная версия все еще работает с .Net Framework 3.5
• Silverlight проекты обновились до Silverlight 4.0
• Silverlight RI обновлены для использования последней версии Silverlight Toolkit.

Скачать можно здесь