What is the .NET 5 way of working with the Windows Shell? [closed]

Question

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?

Mccool

Answer 1

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.

Parsee

While this looks promising, it lacks the one thing I actually use: ShellObject. I'm not sure why it is not included or if it moved namespace, but I could not find it. – Mccool

it is still included: github.com/pierresprim/Windows-API-Code-Pack/blob/master/source/… – Parsee

Great, I found the right NuGet package and it works. – Mccool

Answer 2

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).

Druse

Great answer! I ended up trying to recompile WindowsAPICodePack (the source code is publicly available) but ran into too many problems. Then I started picking just those code files from it I use and integrated that into my project, and that works. So I solved the .NET version issue, but not the maintenance issue - I'll have to maintain it myself now. – Mccool