Complete Environmment.SpecialFolder

[terrajobst]

Filed on behalf of Joel Bennett.

Many of the locations added since Vista are missing.

[Jaykul]

If I understand the new APIs correctly, the problem isn't simply that there are missing locations, the problem is that Environment.GetSpecialFolder is based on the fixed list of CSIDLs which have been deprecated since Windows Vista and replaced with an extensible list...

That is to say, the new IKnownFolderManager API which is now used in SHGetKnownFolderPath, isn't based on a fixed list, but is extensible via the ::RegisterFolder method, so to get the full list you need to call ::GetFolderIds ...

Ultimately, the KnownFolderManager and all the related APIs are completely missing in .Net (although they were implemented in the API CodePack which used to be on the MSDN CodeGallery).

[joshfree]

@terrajobst are you going to flush out the mini-speclet?

[terrajobst]

@Jaykul, are you willing to sketch how you think the APIs should look like? It seems what we need is a different kind of interaction. May be it should be a separate, Windows specific library?

[Jaykul]

Well, if you build it purely based on the Windows APIs, then it's obviously Windows specific -- however, I'm sure that most operating systems have similar common folder paths for at least some of them, and if you implement it based on the KnownFolderManager, you'd be in a sweet spot where each OS can register the folders that it supports and the APIs would basically work the way they're supposed to.

I'm not an expert on these APIs -- I ended up reading the values from the registry for my last project.
Does anyone know who implemented them for the Vista or Windows 7 API CodePack?

For what it's worth ...

I'd start with a KnownFolderCategory and the KnownFolderDefinition, and then write a KnownFolder Manager that supports registering, unregistering, listing registered ids, and looking them up again later.

Somewhere in there I'd throw in a set of pre-defined common ones that I expect every OS to support.

I could flush that out a bit if it would help, but I'd mostly base it off the existing Windows API, assuming they've put a lot of thought into it, and have caught edge cases I wouldn't think of -- like the fact that you can define some common folders purely as nested paths (subfolders) of others (seems obvious now that I've seen it).

[karelz]

Seems to be done by @JeremyKuhne

[knocte]

I only see the Windows impl here: dotnet/corefx@8374092

Is it committed for other platforms as well?

[stephentoub]

https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Extensions/src/System/Environment.Unix.cs#L118

[knocte]

@stephentoub thanks, I've proposed a little fix to this: dotnet/corefx#12575