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