desktop приложение что это
На чем писать мультиплатформенное desktop-приложение? Взгляд менеджера
Сегодня авторы большинства приложений уже не могут позволить себе выпускаться под одну платформу. Early adopters сидят под маками, мейнстрим сидит под Win32, а гики и адепты open source предпочитают Linux. Каждая из этих аудиторий обладает уникальными свойствами, а поэтому важна для большинства проектов.
Данная статья задумывалась как открытая попытка разобраться, на чем стоит писать мультиплатформенное desktop-приложение. Приглашаю высказать свое мнение людей с опытом создания таких приложений.
Изначально определим критерии, по которым будем оценивать различные платформы. В первую очередь — это удобство пользователя. Уверен, что вы замечали общие черты у приложений, написанных под разные платформы. Во вторую — это интересы проекта. Моя задача — построить успешный бизнес, а не играться с различными инструментами.
Обозначим рамки исследования. Мое приложение — небольшая утилита для пользователя-«чайника», которая качает файлы из интернета: минимум GUI, небольшой набор функциональности, использование внешних С++ библиотек.
Ну что, начнем. Какие есть варианты? Я рассмотрю Java, C#, C++, Python. Буду рад, если вы расскажите о других альтернативах.
Данный язык/среда изначально задумывались как нечто мультиплатформенное. На Java написано большое количество приложений, крупные проекты вроде Eclipse используют именно этот фреймворк.
Все приложения, которыми мне доводилось пользоваться, не использовали «родной» интерфейс Win32. Не знаю, чем руководствовались разработчики, но с точки зрения конечного пользователя это выглядит очень не симпатично.
Примеры приложений: Eclipse, ZDE, клиент для Gnutella Limewire.
Плюсы: мультиплатформенность, большое количество кадров, развитость фреймворка.
Минусы: необходимость установки фреймворка, кривость GUI, низкая производительность.
Аналогично с Java, приложения на C# имеют большой минус — необходимость устанавливать фреймворк. Я сам отказался от установки несколько приложений, которые требовали этого фреймворка. Менее продвинутые пользователи будут ещё более требовательными.
В остальном — сплошные плюсы, на мой взгляд.
Примеры приложений😕
Плюсы: мультиплатформенность, большое количество кадров, хорошая производительность, развитость фреймворка.
Минусы: необходимость установки фреймворка.
Старичок дотянул до наших дней и замечательно себя чувствует. Много приложений под платформы Linux и Windows до сих пор пишутся на этом языке.
Программы, написанные на C++, являются примером для других по размеру дистрибутива и экономному использованию системных ресурсов (процессор, память). Тем не менее у разработчиков есть масса претензий к С++. По моему мнению, язык является «устаревшим» и его популярность в дальнейшем будет снижаться, что подтверждается индексом TIOBE.
С точки зрения развития проекта, по сравнению с динамическими интерпретируемыми языками (вроде Ruby и Python), разработка на данном языке может иметь менее высокую скорость и более высокие издержки изменения проекта. Для стартапа, которому не столь важна производительность приложения, это может стать существенным минусом.
Примеры: Firefox.
Плюсы: отличная производительность, большое количество кадров, большое количество библиотек.
Минусы: невысокая скорость разработки.
Python
Взглянуть на Python в качестве платформы для desktop-приложений меня заставила программа MusicBrainz Picard. Несмотря на свою скриптовую сущность, Python легко собирается в один exe-файл, не требуя от пользователя установки дополнительных компонентов.
В случае разработки небольшого приложения, интерпретируемые языки вроде Python будут большим плюсом. Легкость написания и высокая скорость изменения приложения пригодится любому стартапу.
Огромным минусом различных «модных» технологий является их низкое распространение, а значит серьезные проблемы в поиске квалифицированных кадров. Ситуация с поиском программистов итак плачевная, а если ограничиться узким языком — можно вообще никого не найти. С другой стороны, храбрость перейти на новый язык имеют наиболее прогрессивные разработчики. Может получиться так, что выбрав «перспективный» язык, мы сразу отсечем миллионы середнячков, оставив себе выбор из нескольких перспективных разработчиков.
Пример: MusicBrainz Picard, оригинальный BitTorrent.
Плюсы: высокая скорость разработки и изменений, хорошая интеграция с библиотеками на С и С++.
Минусы: мало кадров, низкая производительность.
Выводы
К сожалению, любая из вышеперечисленных платформ имеет свои плюсы и минусы, однозначного решения найти не удалось. Выбор одной из них сегодня принесет преимущества и недостатки, влияние которых на проект мы увидим только завтра.
Я пока выбираю между С++ и Python. Первый является «надежным» решением с известными недостатками. Второй является «рискованным», но интересным и перспективным. Надеюсь, ваши отзывы помогут мне сделать окончательный выбор. Какую платформу выбрали бы вы на моем месте?
PS. Я сейчас ищу программистов в этот стартап (с++/python/php), поэтому если кому интересно — присылайте свое резюме.
Autodesk Desktop App — что это за программа и нужна ли она?
Всем пламенный привет 
Сегодня как всегда я постараюсь выяснить инфу о данной программе, мы поймем зачем она нужна, а вы сможете сделать вывод и смысле ее нахождения на вашем компьютере. Ну что, поехали теперь разбираться 
Autodesk Desktop App — что это за программа?
Я прошустрил интернет и стало все понятно. Давайте я сразу отвечу коротко:
Autodesk Desktop App — это компонент, который позволяет обновить установленные программы Autodesk, получить исправления, а также скачать другое ПО этой компании.
Теперь разбираемся
Разберемся и вы сможете понять — нужна вам эта прога или нет? 
Значит данная программа устанавливается в эту папку:
C:\Program Files\Autodesk\Autodesk Desktop App
PS: Если винда 32-битная, то папка будет Program Files (x86).
И на самом деле все просто — данная прога это некий центр, где можно скачать проги Autodesk, обновить их, а также получить некоторые обновления. То есть это служебное приложение, некая оболочка, просто тоже самое существует и в Adobe — там тоже есть такая небольшая программка, при помощи которой можно скачать другое ПО Адобе. Например поставили Фотошоп — а можно скачать Лайтрум не переходя на офф сайта и вообще не открывая браузер. Но это уже совсем другая история))
Еще важно понимать — когда выйдет новая версия ПО Autodesk или обновление, то прога вас об этом уведомит специальным сообщением. Второе что важно понимать — да, другие проги при помощи Autodesk Desktop App скачать можно, но тут есть условие — у вас должна быть платная подписка ну или скачанные проги будут работать в демо-режиме. Халявы увы тут нет, компания серьезная 
Вот пример — установка приложения Autodesk Revit 2019 и вместе с этой прогой ставится Autodesk Desktop App:
И это вполне нормальное явление. Конечно этот компонент может и не устанавливаться.. если вы скачали прогу с левого сайта, а она уже модифицированная, то есть репак..
Второй пример — тоже самое, только тут уже ПО MAYA, и при установке этой проги тоже ставится компонент Desktop App, вот только именно внизу на картине — ошибка установки:
Ну а вот собственно пример как выглядит сам компонент Autodesk Desktop App:
Как видите — программа как бы является центром, где вы можете установить другие продукты, а также получить обновления ПО. Поэтому, если вы софт купили — эта прога должна в принципе быть вам полезной.
Вот простой пример полезности — представим что у вас установлена серьезная прога Автокад, так вот утилита Autodesk Desktop App — может подсказать, что Автокаду пора обновиться и как видим внизу на картинке — это не просто обновление, а целый пак обнов Service Pack 1 (это означает что будут исправлено сразу много проблем):
Конечно такой пак очень и очень желательно установить, тут сомнений нет. А вот как узнать что пак появился? а скачать его? а поставить правильно? Вот все это — сможет сделать Autodesk Desktop App, в чем и плюс этого компонента 
Нужна ли эта программа на компьютере?
А если удалить? Что будет? Давайте разберемся:
Как удалить?
Удалять нужно только если точно понимаете что в этом есть необходимость. Кстати заранее еще можно создать точку восстановления, тогда если что — сможете быстро все восстановить.
Простой способ удаления:
Заключение
Надеюсь данная информация оказалась полезной. Удачи и добра, до новых встреч друзья! 
Почему «настольные» приложения на компьютере теперь не важны?
На Gizmodo вышла правильная заметка, о том, что нам вскоре не понадобятся полноценные «десктопные» приложения. Эта интересная тема, вокруг которой мы часто крутились. Ваш браузер – это и есть операционная система, и этот подход во многих случаях стирает грань между конкурентными решениями, macOS и Windows.
Нажмите кнопку «Пуск» на «Винде» или «Док» на «Маке» и подумайте: из всего списка настольных приложений, какие вы используете на самом деле, а главное, какие из них нельзя заменить онлайн-версиями программ в браузере? Конечно, найдётся пара, тройка профессиональных решений, если вы графический дизайнер или видео инженер, но если говорить об обычной повседневной жизни и работе?
Вся жизнь в браузере
Браузеры, в частности вездесущий Chrome, стали отдельным миром, в котором происходит большая часть работы.
Офисные задачи легко, а главное удобно воспроизводятся в Google Docs. Музыка и видео прослушиваются «онлайн» и не приходится ничего скачивать. Лёгкие графические редакторы уже давно работают в браузерах. Чего стоит Google Photo со своими возможностями.
Microsoft и Apple реализовали часть ключевых функций своего софта в облаке. Вы можете сидеть на Mac и использовать Microsoft Office в браузере. Или наоборот, сидя за Windows пользоваться пакетом iWork и iCloud от Apple.
Работа с почтой с лёгкостью выполняется через окно браузера, а учитывая вездесущий Google со своими сервисами, то почта автоматически превращается в ежедневник, календарь и файловое хранилище.
Переписка и общение чаще всего выполняются при помощи отдельных клиентов. Telegram, Skype, Slack и прочие сервисы, все они мультиплатформенные, и к тому же все они имеют веб-версию. Не удивлюсь, если через год использовать плагин для браузера, чтобы переписываться в Telegram, будет проще, чем скачать полноценный клиент на компьютер.
В чем плюс отказа от настольных приложений?
Работа в облаке имеет ряд преимуществ. Главное из них, мобильность и лёгкая смена платформ. В любое время и в любом месте вы подходите к компьютеру и не задумываетесь, на какой ОС он работает. Просто открываете браузер, вводите логин и пароль от своей учётной записи Google и ваша рабочая станция готова.
Уход от настольных приложений, которые служили вам на протяжении десятилетий может показаться безумием, но большинство из нас действительно не нуждается в них, так как мы привыкли находить достойную альтернативу в облаке. Лично я не храню документы, фото и видео на диске своего ноутбука и облаку как-то больше доверяю.
Возможно, стоит составить отдельный текст с подборкой сервисов и программ, которые позволяют с комфортом работать в окне браузера.
FlaNium: как сделать тестирование Desktop-приложений под Windows проще
На рынке так много программных продуктов для тестирования, что может показаться, будто для всего найдется готовое решение и нет необходимости тратить время и усилия на разработку инструментов тестирования. На самом деле это не так. Мы в «ЛАНИТ Экспертизе» убедились в этом, когда появилась задача тестирования Desktop-приложений, и теперь делимся с вами опытом.
Источник: kotomatrix.ru
Когда есть доступ к исходному коду и тестирование с разработкой производятся параллельно, то никаких трудностей не возникает, но что делать, когда этого доступа нет и приходится тестировать уже готовый продукт?
В отличие от автоматизации WEB, API или мобильных приложений, тестирование Desktop в некоторой степени – «экзотика», и на это есть несколько причин:
Анализ готовых инструментов
Обзор предлагаемых решений показал, что Open source продуктов не так уж много. Сначала мы испытали Winium – Automation framework for Windows platforms.
Winium – это фреймворк для тестирования Desktop Windows приложений на базе Selenium. Он обладает всеми основными требованиями, которые были необходимы для работы с предстоящим проектом:
Следующим, что показалось нам интересным в плане возможностей, оказалась библиотека FlaUI. Библиотека была написана на C# и не имела какого-либо API для взаимодействия извне. По сути это некая оболочка над библиотеками автоматизации Microsoft Windows Automation API, которая упрощает написание тестов. В отличие от Winium данная библиотека обладает полным функционалом взаимодействия с WinForms и WPF-приложениями, но требует написания тестов на языке C#. Поскольку у нас уже был готовый фреймворк тестирования, реализованный на языке Java, данная библиотека не удовлетворяла наши потребности.
Дальнейший анализ инструментов тестирования показал, что наиболее оптимальный вариант – это реализация своего инструмента. Имеющиеся продукты обладали теми или иными серьезными недостатками, а комбинировать несколько решений не представлялось возможным. Так как абсолютно все Open source решения использовали взаимодействие со стандартной библиотекой Windows Automation API, то было принято решение взять за основу ядро FlaUI Core, построенное на основе взаимодействия с данной библиотекой, и обладающее полным функционалом взаимодействия с элементами тестируемого приложения. Затем добавить поддержку Selenium REST API, аналогично Winium. Так родился проект FlaNium.
Что представляет из себя FlaNium
На данный момент в состав проекта входят пока только два компонента.
FlaNium.Desktop.Driver – основной компонент, представляющий из себя драйвер взаимодействия с тестируемым приложением посредством Windows Automation API и использующий протокол взаимодействия Selenium REST API.
FlaNium.WinAPI – Java-библиотека, расширяющая протокол Selenium REST API и добавляющая дополнительные возможности по настройке и взаимодействию с FlaNium драйвером. Также данная библиотека позволяет типизировать стандартный Selenium WebElement и привести его к компонентам тестируемого приложения, добавляя дополнительные методы взаимодействия, характерные определенному типу элемента.
Рассмотрим пример работы с FlaNium драйвером на базе Selenium Java
Кто хоть немного сталкивался с тестированием, а особенно с тестированием Web-приложений знает, что такое Selenium WebDriver. Есть много информации про Selenium, поэтому в статье мы не будем рассматривать плюсы и минусы, а также особенности работы с Selenium, а рассмотрим лишь особенности работы с FlaNium драйвером.
Перед началом работы с FlaNium драйвером необходимо загрузить последнюю версию драйвера, а также прописать следующие зависимости в pom.xml:
Далее производим настройку и инициализацию драйвера:
После получения экземпляра FlaniumDriver можно осуществлять поиск контролов приложения и взаимодействовать с ними через стандартные методы библиотеки Selenium.
Есть возможность поиска элементов по XPath, Name, Id (AutomationId) и ClassName, а также поддерживаются пять параметров поиска с помощью XPath – AutomationId, Name, ClassName, HelpText, ControlType.
Для более комфортной работы лучше воспользоваться такими инструментами как FlaUInspect, UISpy и подобными, так как они значительно упрощают написание тестов приложения, позволяя визуально отобразить структуру и параметры элементов приложения. Данные инструменты также позволяют понять, как можно обратиться к различным элементам или какие паттерны поддерживает конкретный из них.
Благодаря расширению протокола Selenium есть возможность типизировать любой WebElement и получить дополнительные возможности для работы. Для этого необходимо создать экземпляр требуемого класса и передать WebElement в качестве параметра:
Рассмотрим на примере, для чего нужна типизация и что нам даёт расширение протокола Selenium. Возьмем для примера выбор значения из выпадающего списка:
На рисунке ниже изображено тестируемое приложение (слева) и инспектор (справа):
У нас есть элемент ComboBox, согласно инспектору, доступа к элементам списка у нас нет, чтобы его получить необходимо раскрыть список нажав на кнопку «Открыть».
После раскрытия списка мы получаем доступ ко всем вложенным элементам и можем осуществлять поиск и выбор необходимого элемента.
Вот так будет выглядеть код при использовании стандартных Selenium-методов:
А вот так будет выглядеть то же самое, но при использовании методов типизированных элементов библиотеки FlaNium.WinAPI:
Как мы видим, использование данных методов значительно упрощает взаимодействие и сокращает код. С полным списком поддерживаемых элементов и реализованных методов можно ознакомиться по ссылке.
Мы не изобретали ничего кардинально нового, но взяв в основу преимущества Winium и FlaUI, скомпоновали продукт с удобным универсальным интерфейсом и широкими возможностями взаимодействия с тестируемым приложением. Удалось объединить протокол Selenium REST и библиотеки Windows Automation API.
Давайте рассмотрим, чем же обязан FlaNium этим двум проектам:
На момент написания статьи драйвер уже внедрен в один из наших проектов и успешно работает. Вложив силы и время в разработку собственного драйвера, удалось значительно сократить время и потратить меньше усилий на создание фреймворка и его внедрение, а также сильно упростить написание тестов.
Поскольку драйвер использует универсальный протокол взаимодействия, стало возможным использовать уже имеющийся фреймворк тестирования с некоторыми изменениями. Была добавлена работа с элементами посредством библиотеки FlaNium.WinAPI и реализована логика работы с конкретным тестируемым приложением. Также удалось избежать сложностей при работе с элементами приложения, поскольку используется полноценная библиотека взаимодействия и не возникало ситуаций, когда нет доступа к какому-либо параметру элемента.
Кроме всего перечисленного, внедрение данного драйвера позволило отказаться от вендорского ПО для тестирования, сократив стоимость автоматизации и её поддержки на значительную сумму, а также унифицировать стек технологий и требования к квалификации автоматизаторов.
Мы не останавливаемся на достигнутом и продолжаем развивать данный проект. Помимо взаимодействия с приложениями посредством Windows API ведется разработка технологии взаимодействия с приложением «изнутри» посредством инжекта исполняемой библиотеки в код тестируемого приложения. Данная технология необходима, например, для полноценного тестирования Delphi приложений, чего нельзя добиться с помощью стандартного Windows API.
Публикация десктоп-приложения в Windows Store c помощью Desktop Application Converter
Не так давно мы опубликовали разработанное нами корпоративное приложение для десктопов, которое дополняет функционал Skype for Business. Например, может «по-человечески» сохранять историю переписки, как это делают все «приличные» мессенджеры, умеет отправлять сообщения в оффлайн, позволяет упорядочить контакты и ещё много всего, чего не хватало в Skype for Business. И когда появилась возможность поделиться приложением с помощью Windows Store, мы решили этой возможностью воспользоваться. В статье мы расскажем, как это происходило и чего нам это стоило.
Про сам процесс разработки и про то, чего нам стоила идея работы со SfB в режиме Suppression Mode (подавление SfB), читайте здесь.
EasyLy разрабатывался как настольное приложение WPF & Lync SDK для Windows, и конечно же, мы стремились поделиться своей разработкой со всем миром. Публикация «классических» десктопных приложений (без метро-интефейса) стала доступна не так давно, опыта у нас совсем не было, поэтому мы начали изучать, как загрузить наше приложение в Windows Store.
Начало
Вся суть заключалась в том, чтобы с помощью Desktop Application Converter преобразовать приложение в AppX пакет для UWP (Universal Windows Platform), чтобы затем его можно было загрузить в Windows Store.
Нужно заметить, что не любое настольное приложение можно разместить в магазине. Оно должно удовлетворять требованиям, описанным в этой статье.
Для самого процесса конвертирования необходима ОС “Юбилейное обновление Windows 10 Pro” или “Корпоративная” (10.0.14393.0 и более поздней версии) x64. Также нужно будет установить Microsoft Windows 10 SDK. А перед работой с конвертером понадобится скачать один из базовых образов Windows 10.
ВАЖНО: Версия билда операционной системы должна в точности совпадать с версией образа BaseImage-xxxxx.wim.
После прочтения статьи о том, как работать с конвертером, мы разработали систему скриптов для Command Prompt и Power Shell, которые генерировали AppxManifest.xml и конечный пакет AppX.
И вот, наконец, всё было готово для загрузки EasyLy.appx в Windows Store. Честно говоря, мы не рассчитывали на то, что процесс размещения приложения окажется так растянут по времени, но в общей сложности у нас на это ушло примерно два месяца. Мы также не ожидали, что впереди нас будут ждать странные ошибки, с которыми придётся бороться совместно с сотрудниками Microsoft. Эмоции команды были на переделе, но всё же нам это удалось. О том, что это были за ошибки и как мы их устраняли, читайте ниже.
Ошибка, и не одна.
При первой попытке публикации в Windows Store мы получили четыре ошибки.
Package acceptance validation error: We don’t allow the capability you’ve specified: runFullTrust.
Package acceptance validation error: The PublisherDisplayName element in the app manifest of EasyLy.signed.appx is GROVETY, INC, which doesn’t match your publisher display name: GROVETY INC.
Package acceptance validation error: Apps are not allowed to have a Version with a revision number other than zero specified in the app manifest. The package EasyLy.signed.appx specifies 1.61.6088.26940.
Мы исправили ошибку №3 с версией. Оказалось, что запрещено иметь ревизию версии (последний разряд версии), отличную от нуля (major.minor[.build[.revision]]). Что ж, это было несложно.
Оставались ещё три ошибки.
1. Package acceptance validation error: The PublisherDisplayName element in the app manifest of EasyLy.s.appx is GROVETY, INC, which doesn’t match your publisher display name: GROVETY INC.
2. Package acceptance validation error: You don’t have permissions to specify the following namespaces in the appx manifest file of the package EasyLy.s.appx: schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities
3. Package acceptance validation error: Your developer account doesn’t have permission to submit apps converted with the Desktop App Converter at this time.
Была исправлена ошибка №1 с именем сертификата в AppxManifest.xml:
Если честно, было странно, что это исправление сработало, и непонятно, с каким значением происходит сравнение имени сертификата, т.к. в свойствах AppX пакета в разделе “Цифровые подписи” имя сертификата было как раз с запятой, а к интерфейсу выкладывания в Windows Store разработчики доступа не имели (чтобы посмотреть, как там выглядит имя издателя и что оно вообще там присутствует), потому что публикация осуществлялась отделом маркетинга.
После этого остались ошибки, которые говорили о какой-то проблеме, связанной с аккаунтом, через который было невозможно выложить AppX.
1. Package acceptance validation error: You don’t have permissions to specify the following namespaces in the appx manifest file of the package EasyLy.s.appx: schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities
2. Package acceptance validation error: Your developer account doesn’t have permission to submit apps converted with the Desktop App Converter at this time.
Что делать с этими ошибками нам подсказал один из авторов habrahabr’а — asommer. Как оказалось, все новые десктопные приложения требуют ручной валидации – и для этого нужно написать в техподдержку.
Мы оставили заявку здесь, и уже через несколько дней с нами связался сотрудник Майкрософт.
Поиск решения совместно с Майкрософт
Мы собрали конференцию по Skype for Business, где рассказали, что EasyLy – это десктопное приложение, которое расширяет функционал Skype4B, например умеет сохранять историю диалогов. И по результатам встречи отправили APPX-файл с приложением для проверки.
Также параллельно пришлось подписать ещё одно соглашение с Майкрософт — Centennial Early Adopter Program Addendum.
Общение было затруднено тем, что сотрудники Майкрософт находились в Америке, и разница во времени составляла 10 часов. В результате – приходилось общаться поздно вечером, а ждать ответ на письма – сутки.
Через некоторое время мы получили письмо от Майкрософт. У них возникли вопросы, как EasyLy интегрируется со Skype for Business. Им было необходимо удостовериться, что EasyLy сможет нормально работать со следующей версией Skype for Business.
В общем, нужно было подготовить техническое описание на английском. При этом договорились, что если что-то останется неясным, то будем снова устраивать онлайн-митинг.
К счастью, нашего описания оказалось достаточно, и сотрудник Майкрософт нас заверил, что процесс одобрения идет.
Проверка на прочность
Мы не ожидали, что в Microsoft ещё будут проводиться какие-то тесты над нашим приложением. Представитель Microsoft сообщил, что наше приложение утверждено для Windows Store, но не прошло CARE тест. К тому же, он указал на возможность воспользоваться дополнительными функциями API, доступными только для конвертируемых приложений. Из этих возможностей мы выбрали автозапуск при логине пользователя и добавили в AppxManifest.xml в элемент такой раздел:
Чуть подробнее о тесте CARE. Судя по отчёту прохождения, который они нам прислали, проверяются следующие вещи:
Test for Drivers and Services (Drivers cannot be installed)
Test for DDE Exec registry verbs (DDE Exec warning)
Validate Appx Manifest (Application Identity Name can’t be empty)
Validate security policy settings (EXE can not request admin elevation, EXE can not request UIAccess)
Validate PE integrity (PE Files must be validly signed)
EasyLy провалился на втором пункте. Программа обращалась к нестандартным ключам реестра. Это было исправлено.
Теперь, когда все проблемы были решены, мы предвкушали радость победы и долгожданной загрузки EasyLy в Windows Store. Но удача снова не была на нашей стороне и появились очередные ошибки:
1. Invalid package identity name: EasyLy (expected: GROVETYINC.EasyLyCorp).
2. Invalid package family name: EasyLy_04mzw0hspzxdg (expected: GROVETYINC.EasyLyCorp_8qq6gc35dw28r)
3. Invalid package publisher name: CN=”GROVETY, INC”, O=”GROVETY, INC”, L=Wilmington, S=”Delaware”, C=US (expected: CN=71A49F4D-5C79-40F1-A333-B79F06F50E03)
4. This package uses a display name that you have not reserved: EasyLy
Такое ощущение, что компания Microsoft решила заботливо не сообщать о всех ошибках сразу, а выдавать их по частям, и каждую следующую часть показывать только после исправления всех ошибок в предыдущей. Оно, может, и правильно, потому что если бы мы увидели все ошибки сразу, вероятность того, что мы решили бы продолжать, была бы определенно меньше. Но теперь, когда половина пути была пройдена, отступать назад уже не хотелось.
В Майкрософт ответили следующее:
Error: PowerShell Error Record: Could not find a part of the path. PowerShell Stack Trace: at