I recently moved some of my software projects to .NET 5. I use the Microsoft WindowsAPICodePack to work with the Windows Shell, but this library is getting old and does not seem to be maintained anymore. Also, it's compiled for .NET Framework 4.7 or 4.8 and might be incompatible with .NET 5. So what is the 'proper' (as in best, modern) way to work with the Windows Shell from a .NET 5 app. For example, I use the old API code pack to get a user's libraries, get file icons etc. I noticed there is the namespace Windows.Storage which seems to have some or maybe all of this functionality, but it seems to be more targeted to UWP (maybe that doesn't matter much for a .NET 5 project?). Or do I need to look into WinRT? Any ideas?
3 Answers
The package WinCopies.WindowsAPICodePack.Shell was updated to 2.1.0, which brings .Net Core 3.1 and .Net 5.0 support:
So add the package
<PackageReference Include="WinCopies.WindowsAPICodePack.Shell" Version="2.1.0" />
and target your app as net5 and use the API like you did with the original package from Microsoft.
So what is the 'proper' (as in best, modern) way to work with the Windows Shell from a .NET 5 app
Officially, I don't think there is one. That is, it's undefined.
I note that C# and .NET really don't present the best developer UX for working with COM - it's a shame that in 2020 the best language for consuming COM is still VB6 and the best language for writing for COM is C++.
Though remember that WinMD and C++/CX is about modernising COM and it's the basis for WinRT and UWP - so I expect that most of the older shell functionality will be exposed through there which should be easier to consume than using COM interfaces directly. I also note that a lot of UWP's APIs are now available to non-sandboxed applications as well.
Someone did ask Microsoft to include the port in the now open-source WinForms project, but it was declined as being out-of-scope. (boooo!)
I use the Microsoft WindowsAPICodePack to work with the Windows Shell, but this library is getting old and does not seem to be maintained anymore. Also, it's compiled for .NET Framework 4.7 or 4.8 and might be incompatible with .NET 5.
Indeed. I don't believe it will work as-is, however the WindowsAPICodePack is a very thin wrapper over Win32's Shell COM interfaces, so it should be straightforward to dump the assembly using ILSpy and recompile it for .NET Standard 2.0 (so you can continue to use it in .NET Core, .NET 5 and .NET Framework projects).
An alternative library might be https://github.com/dahall/Vanara, essentially a collection of wrappers for almost all native Windows APIs, including the shell API.
Related