>>You'd only be using a mapped drive letter temporarily, to work around a hole in the .Net framework; and cleaning up after yourself. IMO much cleaner than parsing the results of a DIR command, which strikes me as being very fragile. It might be affected by DIRCMD, maybe European users get results in a different language, or they use "." instead of "," as thousands separator etc. etc.
>
>We just cannot map a drive letter, either permanent or temporary.

Well, to me that's a mystery. What I'm suggesting is temporarily mapping a drive, probably for less than one second (depending on how fast the .Net DriveInfo class can retrieve the data).

I've never seen a security policy where mapping drives is disallowed, I'm not sure it exists. If you have read/write privileges to a network share, there are no security or other implications to allowing mapping of drive letter(s) to that share, it's simply an alias on the client. No different from using SUBST to map a drive letter to a local folder.

OTOH spawning a secondary CMD process is something that may be frowned upon from a security POV. It would not surprise me if some locked-down environments disallow that. You can map a drive without access to CMD using the first link I posted earlier.

If on the other hand it's your development policy to never used mapped drive letters, well and good, but it's stopping you from getting the optimum results in this case.