От концепции к завершению: путь приложения

История приложения для безопасной корзины

От концепции к завершению: путь приложения — часть VI

Часть VI → Кроличьи норы и глубокие пещеры кода

Посмотрите, о чем эта история — https://blackhole2020.app/

TLDR;

Глубокое погружение в различные проблемы UWP для тех, кто осмелится (предупреждение о большом количестве исходного кода)
Долгий путь через кроличьи норы и как их избежать
Как мне удается не #ragequit несмотря на все неудачи

Глубокое погружение в царство кодов

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

Я чувствую, что проблемы, с которыми я столкнулся, и то, как я их преодолел, могут быть весьма полезны для других, поэтому мне нравится вести их хронику. Приятно с головой окунуться в то, что в то время кажется совершенно невозможным, но в конце концов становится вполне возможным. Бывают моменты синдрома «Думаю, я сейчас выкину этот ноутбук в окно». Но, возможно, именно они делают победу еще слаще.

Темная сторона UWP

Я знал, что использование новейшей платформы Windows 10 (UWP) будет иметь некоторые минусы и недостатки. Я столкнулся с ними головой вперед, когда пытался получить доступ к файлам. В таких простых вещах, как попытка реализовать перетаскивание файлов/папок, проявились первые проблемы.

Для краткости: я разрабатываю приложения C++/C# WinForms, WPF и Swift для iOS более десяти лет и являюсь компьютерным инженером с классическим образованием, поэтому я «знаю свой путь» в коде. Например, я знаю то, чего не знаю 😆. Я ни в коем случае *нет* не являюсь экспертом, за исключением разве что перенесения страданий, ха-ха.

Я предполагаю, что проблемы ожидаются, поскольку UWP теперь является несколько кроссплатформенным, возможно, предназначенным для мобильных устройств и планшетов, поэтому есть много новых ограничений (а поскольку это программа для удаления файлов, нам вроде нужно доступ…😆)

Отличия от WPF начались сразу….

UWP требует запросов разрешений в стиле мобильных устройств (например, телефонов) и разрешений в XML-файлах при настройке. WPF ничего из этого не требовалось.
https://docs.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations
Что еще более важно, UWP, похоже, использует новые объекты класса (содержащиеся в Windows.Storage ), которые, извините за мои слова, дерьмовые с точки зрения производительности. Попытка перечислить 60 000 файлов на моем высококачественном твердотельном накопителе Corsair заняла 99 секунд… тьфу. Что случилось Майкрософт?? Я нашел несколько статей о том, как обойти это, но это не было проблемой в WPF. Это довольно неприятно, когда вам нужно сразу же обойти базовые функции уровня Framework! В конце концов, есть много способов обойти это, но странно прыгать в новый фреймворк, и вдруг все становится сложнее, а не меньше.
https://docs.microsoft.com/en-us/windows/uwp/files/fast-file-properties
Обработчики стали асинхронными, и доступ обратно к потоку пользовательского интерфейса теперь проблематичен. Я провел несколько часов, застряв на проблемах Dispatcher, когда потоки отказывались фактически отправляться на главную страницу, и поэтому он просто постоянно зависал.
https://docs.microsoft.com/en-us/windows/uwp/design/input/drag-and-drop
Отладка изменилась. UWP больше не настроен для отображения необработанных исключений в обработчиках асинхронных событий, когда вы делаете что-то не так. Теперь вы должны настроить смешанную/собственную отладку и попытаться выяснить, где находятся файлы символов. Еще одна многочасовая кроличья нора.
https://stackoverflow.com/questions/37373043/uwp-a-debugger-is-attached-to-exe-but-not-configured
Когда я наконец настроил файл символов, мне потребовалось несколько минут только для того, чтобы запустить мое приложение отладки. И это на совершенно новом настольном процессоре AMD Ryzen3 с 64 ГБ оперативной памяти. Я не могу представить, насколько ужасно это было бы на более старой/медленной системе. Так что… пришлось отключить эту опцию. Нет, спасибо! 😳
Однако без символов вы не сможете получить какие-либо реальные ошибки от обработчиков асинхронных событий… так что вы, по сути, летите вслепую. Требуется просто выяснить неисправный код без какой-либо обратной связи! Ах, как в старые добрые времена… Может быть, Microsoft пытается нам что-то сказать? 😆
Все это можно было бы обойти, но, как я уже сказал выше, все внезапно стало более сложным, а не менее, ни одна из этих проблем не была проблемой за последние 10 лет существования C#. Какое разочарование.

Итак… жалею ли я, что выбрал UWP?

Нет, не совсем… Я выбрал этот путь, прекрасно зная об опасностях. Мне нравится, как быстро появился анимационный фреймворк Lottie и горячая перезагрузка приложения. Я думаю, что многие будущие проверки будут «встроены» в кодовую базу, но я могу ошибаться в этом. Я почти уверен, что фреймворк Лотти не будет нормально работать даже в старых .NET/WPF. Этот путь кажется довольно типичным: фреймворкам нового поколения требуется несколько лет, чтобы улучшиться до уровня зрелости, который был у старых, а затем, наконец, превзойти его. Вы, конечно, больше не увидите людей, требующих написания приложений WinForms!

Я говорю: настаивайте.

Ради интереса я все равно попытался откатить код в проект WPF с поддержкой Lottie, но единственный проект Lottie github, который я смог найти в Nuget/Github, вообще не работал с моей анимацией json (ошибки не было, просто нулевые ссылки на объекты) . WPF также не поддерживает предварительный просмотр анимации в реальном времени, так что на самом деле ничего не работало. Мне кажется, UWP — это путь вперед или ничего! Сожгите корабли! (без отступления)

вспахивая

На этом этапе умирают проекты.

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

Вот ты и уволился.

Однако… именно сейчас, когда я пишу это, я обнаруживаю решение проблемы, над которой я застрял на 8 часов. Забавно, как это работает, а? Найдите минутку, чтобы подумать, написать, и решение прокрадется через заднюю дверь нашего разума.

Ошибка: при программном добавлении элементов в C# Canvas параметр Top/Left *не должен* быть установлен следующим образом: canvas.left = 0 (что разрешено, но никогда не работает), вместо этого необходимо использовать

Canvas.SetLeft(element, 0);

Поди пойми правильно? Проблема в том, что, если вы помните, отладчик не работает сразу в асинхронных обработчиках, поэтому он не может выдать мне ошибку! Я должен был учуять это сам. *кивает богам кулаком* UWP!!!

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

Делаем анимацию интересной

Первая серьезная проблема кодирования, которую необходимо решить, — это создание чего-то интересного из файлов JSON-анимаций. Когда пользователь хочет удалить файлы, он обычно не стирает 1 или 10 файлов, обычно это 100–100 000–10 миллионов. Таким образом, очевидно, что скользящее соотношение шкалы в порядке, но что?

Это самое интересное!

Здесь есть две основные проблемы:

1) Запросы к файлам очень медленные и нуждаются в некоторых интересных обходных решениях с использованием многопоточных подходов. Ака эта строка:

Эта функция может занять минут для ‹ 100 000 файлов, поэтому ей явно нужна помощь.

2) Простота кода.

Мой общий подход заключается в использовании максимально простого кода, потому что мой главный приоритет состоит в том, чтобы он никогда не давал сбоев. В качестве сольного проекта я бы предпочел немного более уродливый код, который никогда не дает сбоев, чем элегантную, но чрезмерно сложную парадигму дизайна, в которой есть гнусные, трудно отслеживаемые ошибки. Чтобы правильно реализовать шаблоны, требуется много навыков и практики, и если все сделано неправильно, они намного хуже, чем полное отсутствие шаблонов. Цель этого проекта не в том, чтобы увязнуть в изучении новой парадигмы, поэтому важно помнить об этом для всех программных проектов. Есть только один из вас! Где лучше всего проводить время? Если проект застопорится, он, скорее всего, вообще никогда не увидит свет, так что это мой аргумент в пользу все равно писать уродливый код. Вы всегда можете вернуться и почистить его, если каким-то образом напишете следующий Твиттер 😁.

Общее примечание на данном этапе проекта. Сон имеет решающее значение! Я чувствовал себя немного застрявшим и не спал до 3 часов ночи, работая над кодом несколько ночей… начинает быстро давать уменьшающиеся результаты. Вместо этого 11-часовой сон, когда тело говорит вам, часто приводит к прорыву в течение 30–60 минут после пробуждения (из опыта).

Не стоит недооценивать эпическую силу сна.

Кроме того, что лучше? Не спать в течение 4 часов, забивая голову проблемами… или спать, пока не почувствуете себя очень отдохнувшим, и решать ту же проблему за 1/4 времени? Мало того — теперь у вас есть 3/4 этого времени, чтобы заняться чем-то другим, а также просто быть в намного лучшем настроении! Это тот же аргумент в пользу игры вместо постоянной работы.

Правильно. Жизнь разглагольствования закончилась. Вернуться к коду.

Переходим к следующему интересному решению — динамическому размещению файлов JSON в радиусе вокруг черной дыры. Я попросил дизайнера создать 6 разных файлов JSON, в основном сверху/посередине/снизу/слева/справа. Затем я разделяю холст на 6 областей и динамически изменяю файл JSON во время выполнения, чтобы анимировать правильное направление (к черной дыре).

Здесь недостаточно места, чтобы поделиться полным кодом, поэтому я сосредоточусь на том, чтобы поделиться интересными частями.

Во-первых, просто создайте пользовательский XAML UserControl с анимацией Lottie, как показано ниже. Можно, конечно, заменить чем угодно.

<Grid>
<muxc:AnimatedVisualPlayer AutoPlay="True" x:Name="animate_disintegrate">
<lottie:LottieVisualSource x:Name="lottie_disintegrate" UriSource="ms-appx:///File_Disintegration_MidRight.json"/>
</muxc:AnimatedVisualPlayer>
</Grid>

Суть в том, что мы будем использовать логику такого типа:

switch (dir)
{
case FileDisintegrationDirection.TopLeft:  json += "File_Disintegration_TopLeft";       break;
case FileDisintegrationDirection.TopRight: json += "File_Disintegration_TopRight";      break;
case FileDisintegrationDirection.MidLeft: json += "File_Disintegration_MidLeft";        break;
case FileDisintegrationDirection.MidRight: json += "File_Disintegration_MidRight";      break;
case FileDisintegrationDirection.BottomLeft: json += "File_Disintegration_BottomLeft";  break;
case FileDisintegrationDirection.BottomRight: json += "File_Disintegration_BottomRight";break;
}
json += ".json";
lottie_disintegrate.SetSourceAsync(new Uri(json));

Функция SetSourceAsync() — это то, что я искал некоторое время. Я попытался связать источник XAML Uri, но это не сработало — вы должны вызвать эту функцию, иначе библиотека Lottie не перезагрузит функцию. Это то, что а) никем не задокументировано и б) потребовалось несколько часов, чтобы понять. Так просто в исполнении, но так долго искать. Вот почему они платят программистам большие деньги, а?

Логика определения области на экранах — это простая математика.

«Если пиксель x меньше половины ширины экрана» и «если пиксель y меньше одной трети высоты» хорошо делит экран на 6 квадрантов. Каждый файл анимации специально предназначен для распада в центре экрана.

if (x < width / 2)
{
if (y < height / 3)

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

Смещение здесь является ключевым, потому что маловероятно, что анимация JSON идеально центрирована относительно своей оси (в отличие от моей). И для справки, XAML использует верхний левый угол как 0,0 (по причинам, которые меня не волнуют). Каждый язык устройства имеет свое собственное чертово x/y происхождение пикселей (почему кто-то не может стандартизировать это, ха-ха).

Самое время избавиться от старой тригонометрии!

foreach (var file in files)
{
File file_json = new File();
// generate random position around the radius of the black hole
var random = new Random();
var radius = random.Next(240, 275);
var offset = 75;  // the file animation isn't perfectly centered so we need to re-center manually
var angle = random.NextDouble() * Math.PI * 2;
var x = Math.Cos(angle) * radius + radius - offset;
var y = Math.Sin(angle) * radius + radius - offset;
//Debug.WriteLine("generating x/y = " + x + " " + y);
Canvas.SetLeft(file_json, x);
Canvas.SetTop(file_json, y);
file_json.Width = 150;
file_json.Height = 200;
file_json.SetDirection((int)x + offset, (int)y + offset, (int)cnvFiles.Width, (int)cnvFiles.Height);

Этот аккуратный фрагмент кода ниже запускается, когда анимация Lottie добавляется на холст. Примечание: вы не можете использовать событие загрузки XAML, потому что анимации Lottie загружаются после этого. Поэтому мне пришлось копаться в документации по конкретному событию AnimatedVisualPlayer, которое в конечном итоге сработало.

animate_disintegrate.RegisterPropertyChangedCallback(AnimatedVisualPlayer.IsAnimatedVisualLoadedProperty, handle_is_animated_visual_loaded);
private void handle_is_animated_visual_loaded(DependencyObject sender, DependencyProperty prop)
{
// TODO -- can put animation delay here in background thread that invokes the UI to call play
animate_disintegrate.PlayAsync(0, 1, false);
}

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

Проблемы с производительностью

Далее мы имеем дело с ужасной производительностью поиска файлов + анимаций. Обе серьезные проблемы, которые заставят приложение работать как дерьмо, если я не разберусь с этим!

Проблемы с анимацией

После одновременного добавления даже 25 или 50 файлов анимации JSON в контейнер холста производительность приложения во время выполнения ужасна. Лотти не может одновременно анимировать такое количество файлов. Теперь это *может* быть отладчиком, замедляющим работу. Всегда стоит помнить, что отладочный код часто работает медленнее. Это распространенная проблема, с которой я уже сталкивался на бесчисленных платформах, поэтому всегда стоит проверить производительность режима выпуска, прежде чем слишком волноваться.

Но даже до того, как мы это проверим, мне не нравится идея добавлять сотни анимационных XAML в Canvas и никогда не избавляться от них, когда они закончат воспроизведение анимации. Это называется адом памяти (т. е. объем памяти станет слишком большим, быстро превысив 1 ГБ!)

Файлы Lottie и JSON маленькие и шустрые, но даже они занимают много памяти при анимации на экране.

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

Я пытался использовать AnimatedVisualPlayer.IsPlayingProperty, но увы, это не сработало! Я сделал быстрый тест, чтобы увидеть, правильно ли возвращается логическое значение true/false, но оно срабатывает «false» задолго до того, как JSON успел отобразиться на экране. Так что... понятия не имею, почему. Вместо того, чтобы возиться с этой кроличьей норой, я ненадолго подумал об использовании ручного таймера, который удалял бы анимацию по завершении, но это не очень хорошо работало со списком дочерних элементов Canvas. Список не поддерживает удаление определенных элементов по индексу (он просто удаляет случайные элементы). Попытки обойти это ограничение чаще всего встречались segfault и/или удалением с экрана неправильных объектов.

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

Лучший способ? Цикл анимации.

Рассинхронизация анимации с фактически стираемыми файлами оказалась моей идеей сделать эту реализацию действительно простой. Хотя забавно представить, что анимация буквально привязана к стираемым файлам, это излишне усложняет реальную логику кода. Честно говоря, нам просто повезло, что у нас есть фреймворк, который так же хорошо работает с JSON :) Скорее всего, он не был разработан для того, что я с ним делаю!

Моя идея состоит в том, чтобы разделить анимацию на логарифмически масштабированную, которая отображает анимацию отдельных файлов на основе общего количества стираемых файлов. Грубый пример: ‹ 100 файлов — это ~5 файлов за раз, тогда как 100 000 файлов могут быть ~25 файлами за раз. Судя по моим первоначальным тестам, наличие более 25 файлов JSON на экране в любой момент времени кажется неприемлемым отставанием.

Эта проблема с производительностью Lottie позже появится и в MacOS. Возможно, поэтому я редко вижу применение Лотти на практике? С этим конечно не легко справиться.

Мне нравится мощь UWP здесь. Простое, забавно выглядящее лямбда-выражение переводит код в фоновый режим, поэтому мы можем безопасно заснуть Thread, в то время как использование ключевого слова await с диспетчером позволяет коду добавлять анимацию на экран. async — это новый UWP/C#-изм, который позволяет асинхронному коду фактически блокироваться «волшебным образом» — согласно документации, ха-ха. В данном случае это помогает, потому что file_animation_time_secs — это как раз продолжительность файлов JSON, которые я анимирую, поэтому приятно не добавлять смещение на время, необходимое для загрузки файлов на холст XAML пользовательского интерфейса.

Любой процесс, который изменит files_erasing на false, остановит поток анимации и очистит себя. Ах! Современное потоковое программирование!!

Релизная сборка = не наш спаситель

Переключение в режим Release, похоже, немного улучшило производительность, но в основном проблемы остались. Я думал, что использование JSON и Lottie позволит отображать на экране множество анимаций с хорошей производительностью из коробки, но я ошибался! Производительность даже 100 одновременных анимаций JSON (JSON составляет 155 КБ для справки) ужасна. Приложение быстро превышает 1 ГБ ОЗУ, загрузка процессора резко возрастает, и даже моя музыка Spotify заикается при воспроизведении (на AMD Ryzen 3900X не меньше, ха!)

Итак, надежды на режим Release не оправдались. Нам придется прибегнуть к хитрости под капотом, чтобы воплотить в жизнь убедительно сложную анимацию, не доводя до ‹ 10 кадров в секунду, что очень заметно для глаз. Меня также беспокоит, как он будет работать на более дешевых машинах (не все хотят покупать 12-ядерный процессор за 500 долларов, ха-ха).

Плохой встроенный поиск файлов в UWP

Это настолько плохо, что в MSDN буквально есть статьи о том, насколько это плохо, поэтому вы можете обойти это. Мои тесты аналогичных вызовов доступа к файлам в WPF не так уж и плохи.

Под плохим мы подразумеваем 45 000 файлов, которым требуется несколько минут для возврата из вызова функции. Это ничего! Очевидно, что приложение, предназначенное для стирания файлов, захочет просмотреть миллионы файлов в наших современных системах.

Быстрый доступ к свойствам файлов в приложениях UWP
Узнайте, как быстро получить список файлов и их свойств из библиотеки и использовать эти свойства в приложении…docs.microsoft.com

Вышеприведенная ссылка объясняет сделку… очевидно, для этого потребуются те же махинации, что и для анимации. Мне просто грустно, что мы требуем махинаций буквально с самого начала — и что они официально от Microsoft!

Так да. Код выглядит таким простым, но, о боже, производительность такая плохая. Ссылка предоставляет в основном бесполезный код — для меня странно, что он уже не встроен в API! MICROSOFT *трясет кулаком*

Кроличья нора продолжается

В этот момент я понимаю, почему не так много статей и помощи UWP на эту тему. Проблемы продолжались, пока я углублялся в проблемы, связанные с «песочницей UWP», как ее считала Microsoft. По сути, приложения UWP «предполагаются» оставаться на месте — то есть Microsoft решила, что эта технология не предназначена для системных утилит, таких как стирание файлов. Они, безусловно, ужасно усложняют получение доступа к файлу для записи чего-либо за пределами каталога приложения. Даже прочитав кучу статей о доступе к файлам в MSDN, он все равно не работает…

Многие поиски в Google позже, и после многих подобных статей о медленной смерти фреймворков Microsoft… Я нахожусь на интересном перекрестке, где я подумываю вернуться к WPF еще раз.

Microsoft отказывается от UWP и повышает Win32 | Hacker News
UWP с самого начала был дерьмом, особенно после того, как все поняли, что MS намерена отказаться от мобильных устройств…news.ycombinator.com

Однако я не из тех, кто просто слепо доверяет циничному характеру паутины. Конечно, это выглядит мрачно… но я настаиваю. В конце концов, может быть, через 4–5 часов гугления я нашел этот блог о расширениях рабочего стола UWP…

UWP с расширением для рабочего стола — часть 1
Добавление компонента расширения для рабочего стола в пакет приложения UWP — отличный способ сделать универсальное приложение еще лучше на…стефанвике .com

Итак, после почти поражения от сбоя интерфейса Windows UI StorageFolder/File (я имею в виду, что у него даже есть эпически длинная страница жалоб на GitHub — https://github.com/microsoft/ProjectReunion/issues/8), я думаю, я нашел способ!

Честно говоря, весь процесс проверки приложений в Microsoft Store звучит так, как будто они могут полностью ненавидеть то, что я здесь делаю, поэтому я могу избежать некоторых ограничений, не беспокоясь о выпуске в магазине.

Расширения рабочего стола UWP, острова, о боже

Еще одна кроличья нора… ура?

Понятия не имею! Я также обнаружил уморительно названную концепцию Microsoft под названием «Остров XAML»... по сути, кажется, что я могу написать приложение C# WPF и использовать компоненты пользовательского интерфейса UWP (например, библиотеку Lottie ) в качестве компонента. Никогда так не пробовал… оставляю на крайний случай, если ничего не помогает. У WPF есть «обычный» доступ к файловой системе, так что больше не нужно ограждаться безумием UWP.

Так что на данный момент эта функция «Расширения рабочего стола», похоже, работает… но, черт возьми, она замедляет отладку, компиляцию / время выполнения… и это на 12-ядерном современном мега-звере AMD Ryzen 3. Абсурд! По крайней мере, метод, описанный в статье, сработал, консольное приложение стороннего проекта запускается. Так что это может быть единственным способом обойти проблему ограждения на данный момент.

Фехтовать или не фехтовать — вот в чем вопрос?

Таким образом, эта статья оказывается удивительным ресурсом. Чтобы добраться до него, потребовалось всего 15 часов поиска в Google, но оно того стоило! Я не очень в восторге от необходимости разбивать код на отдельные процессы, но Microsoft оставляет мало места, когда они ломают / калечат / полностью разрушают свои собственные API доступа к файловой системе. *пожимает плечами* Полагаю, они указывают разработчикам делать это таким образом? В Риме…

Многие пикантные подробности содержатся в статье в блоге выше, но я хочу вкратце коснуться того, как я конкретно разработал этот предмет, чтобы он стоил того, чего он стоит!

Решил запустить приложение WPF в качестве второго «расширения», поскольку WPF имеет отличный доступ к API ввода-вывода файлов и его легче писать, чем WinForms или C# Console.
Удалено окно из App.xaml, также известное как строка StartupUri="MainWindow.xaml". Таким образом, процесс является «фоновым».
Используя третью статью из блога, настройте соединение AppService между двумя процессами. Это потребовало добавления в проект WPF множества ссылок на фреймворк, которые не были частью статьи. Я имею в виду, что мы говорим здесь о темных искусствах Windows. Я часами переполняла StackOverflow самыми смехотворно случайными проблемами вроде «почему эта ссылка на Windows.Foundation случайно скрыта?»
Именно здесь, в этот момент, люди проклинают разработку Windows. Честно говоря, это шутка. Необходимые расширения не отображаются, и вам приходится искать случайную информацию без уважительной причины. В этот момент я, вероятно, сказал бы всем: откажитесь от приложений UWP, чтобы избежать будущего ада обслуживания!

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

Например, вы получаете вот такие официальные ответы Microsoft github от 2020 года — они просто сдаются. Функции, необходимые для этой статьи выше, просто сломаны и/или недоступны.

Не удается добавить пакет nuget System.Runtime.WindowsRuntime в проект .net 4.6.1 · Проблема № 21942 ·…
Если вы попытаетесь добавить пакет, вы получите следующая ошибка: Не удалось установить пакет «System.Runtime.WindowsRuntime…github.com

Я нашел способ обойти это. Это потребовало еще одного неясного поиска в Google об этой причудливой строке версии 255.255.255.255 в сообщении об ошибке выше. Оказывается, сборка Windows.Foundation.UniversalContract просто несовместима с WindowsRuntime. И среда выполнения NuGet тоже не работает, поэтому… вы можете найти два соответствующих файла, уже являющихся частью Win10 SDK, здесь:

C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.18362.0\Windows.winmd
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5\System.Runtime.WindowsRuntime.dll

И ЭТО РАБОТАЕТ!!!

Это из кода WPF, работающего как расширение рабочего стола. Нет никакого сравнения… 170 000 файлов за несколько секунд по сравнению с горячим мусором, которым является производительность доступа к файлам UWP.

Идти дальше

Всего этого успеха еще недостаточно… ха-ха. Чтобы правильно стереть большинство файлов в вашей системе во время очистки, процесс должен выполняться в режиме администратора, иначе большинство вещей, помеченных как «только для чтения», таких как файлы в Program Files и других местах, не будут работать с исключениями доступа. И мы никоим образом не просим пользователей исправить это вручную.

Этот блог оказался отличным. Все необходимые ответы были как в самом блоге, так и в длинных разделах комментариев под каждым постом. Похоже, что большинство функций, необходимых для UWP, не были реализованы до конца 2018/2019 года! Как хорошо, что я не пытался написать это приложение раньше :)

Примеры повышения уровня приложения — часть 3
Если вы еще не читали части 1 и 2 этой серии, начните сначала с них. Я рассмотрел «привет, мир…stefanwick.com»

После подробного прочтения статьи … кажется, что всегда будут проблемы с UWP и всем, что требует «повышенных» разрешений, таких как права администратора. Без них в Windows просто чертовски сложно сделать что-то ДЕЙСТВИТЕЛЬНО ПОЛЕЗНОЕ. Очевидно, что стирание файлов просто не будет работать без него. Однако, согласно блогу, просто нет возможности общаться из процессов UWP-› с повышенными правами. Так что мы облажались в основном. Несмотря на то, что процесс с повышенными правами может быть создан, его нельзя остановить, что недопустимо.

На этом этапе я собираюсь остановить проект (снова) и исследовать эти забавные названия… XAML-островков. Я сразу понимаю, что недостатком является то, что им требуется последняя версия Windows 10 2019 года, но на дворе 2021 год… кто же до сих пор использует версии 2018 года?! К черту обратную совместимость!

Не волнуйтесь пока

Час спустя и важная страница Github позже… кажется, что XAML Islands еще слишком сырые, чтобы их можно было использовать для анимации Lottie. Критические элементы управления композицией пользовательского интерфейса еще не работают на островах, и Microsoft довольно медленно обновляет это (сообщениям уже год). Может быть, это когда-нибудь изменится! Но пока… вернемся к ужасным обходным путям в стране UWP. Неудивительно, что никто еще не использует приложение Lottie для Windows! Я очень надеюсь, что сторона MacOS в этом бизнесе пойдет НАМНОГО лучше! (Глядя на ВАС, Apple)

Ну, это было быстро, не так ли.

[WPF] Lottie-Windows в приложениях WPF · Выпуск №132 · windows-toolkit/Lottie-Windows
sohchatt изменил название Не могли бы вы предоставить средство просмотра на основе WPF? [WPF] Lottie-Windows в приложениях WPF, 27 августа 2019 г. Вы…github.com

УРА!

Это много. Так что на данный момент было много прогресса и бесконечных препятствий. Это всегда хороший момент, чтобы хорошенько выспаться и вытащить самолет для атаки утром. Я буду впечатлен, если вы будете следить за всем этим. Возможно, это вдохновило вас на что-то. Это было бы просто великолепно ❤️.

Предыдущая часть →https://medium.com/geekculture/from-concept-to-completion-the-journey-of-an-app-part-v-6db34e089500

Надеюсь увидеть вас в следующем!

Если эта история вдохновила вас на что-то, я буду рад услышать. Напишите мне в любое время!

-Джонатан | с ❤️ 🎶 ☕️

От концепции к завершению: путь приложения — Часть VI

История приложения для безопасной корзины