Как .NET 5 работает с оболочкой Windows?
Недавно я перенес некоторые из своих программных проектов на .NET 5. Я использую Microsoft WindowsAPICodePack для работы с оболочкой Windows, но эта библиотека устаревает и, похоже, больше не поддерживается. Кроме того, он скомпилирован для .NET Framework 4.7 или 4.8 и может быть несовместим с .NET 5. Итак, каков «правильный» (в лучшем случае, современный) способ работы с оболочкой Windows из приложения .NET 5. Например, я использую старый пакет кода API для получения пользовательских библиотек, значков файлов и т. д. Я заметил, что существует пространство имен Windows.Storage, которое, кажется, имеет некоторые или, возможно, все эти функции, но, похоже, оно больше ориентировано на UWP (может быть, это не имеет большого значения для проекта .NET 5?). Или мне нужно изучить WinRT? Есть идеи?
Ответы 2
Итак, каков «правильный» (как в лучшем, современном) способ работы с оболочкой Windows из приложения .NET 5.
Официально я не думаю, что он есть. То есть он не определен.
Я отмечаю, что C# и .NET действительно не представляют лучший UX для разработчиков для работы с COM — обидно, что в 2020 году лучшим языком для использования COM по-прежнему остается VB6, а лучшим языком для написания COM — C++.
Хотя помните, что WinMD и C++/CX предназначены для модернизации COM и являются основой для WinRT и UWP, поэтому я ожидаю, что большая часть старых функций оболочки будет доступна через них, что должно быть проще для использования, чем использование интерфейсов COM напрямую. . Я также отмечаю, что многие API-интерфейсы UWP теперь доступны и для приложений без песочницы.
Кто-то попросил Microsoft включить порт в проект WinForms с открытым исходным кодом, , но он был отклонен как выход за рамки . (буооо!)
Я использую Microsoft WindowsAPICodePack для работы с оболочкой Windows, но эта библиотека устаревает и, похоже, больше не поддерживается. Кроме того, он скомпилирован для .NET Framework 4.7 или 4.8 и может быть несовместим с .NET 5.
Действительно. Я не верю, что он будет работать как есть, однако WindowsAPICodePack представляет собой очень тонкую оболочку над COM-интерфейсами Win32 Shell, поэтому должно быть просто выгрузить сборку с помощью ILSpy и перекомпилировать ее для .NET Standard 2.0 (так что вы можете продолжить использовать его в проектах .NET Core, .NET 5 и .NET Framework).
Пакет WinCopies.WindowsAPICodePack.Shell был обновлен до 2.1.0, что обеспечивает поддержку .Net Core 3.1 и .Net 5.0:
Итак, добавьте пакет
<PackageReference Include = "WinCopies.WindowsAPICodePack.Shell" Version = "2.1.0" />
и нацельте свое приложение на net5 и используйте API, как вы делали с исходным пакетом от Microsoft.
Хотя это выглядит многообещающе, в нем отсутствует одна вещь, которую я действительно использую: ShellObject. Я не уверен, почему он не включен или он переместил пространство имен, но я не смог его найти.
он все еще включен: github.com/pierresprim/Windows-API-Code-Pack/blob/master/source/…
Отлично, я нашел правильный пакет NuGet, и он работает.
Отличный ответ! В итоге я попытался перекомпилировать WindowsAPICodePack (исходный код общедоступен), но столкнулся со слишком большим количеством проблем. Затем я начал выбирать из него только те файлы кода, которые я использую, и интегрировал их в свой проект, и это работает. Итак, я решил проблему с версией .NET, но не проблему с обслуживанием - теперь мне придется поддерживать ее самостоятельно.