Question

I am working on a Metro app that shows the content of a given folder in a ListView control. MS decided that developers don't need the System.IO.Directory class and removed it entirely from the framework.

I am looking for a replacement to enumerate files in C# in a metro style app. I have checked all the enumeration samples provided by MS and they all seem to only enumerate the Windows Libraries using the KnownFolders class, something like:

StorageFolder picturesFolder = KnownFolders.PicturesLibrary;

and calling the GetFilesAsync() or GetFoldersAsync() methods depending on your needs. These are all gold if I wanted to enumerate only inside the pictures or music library. However I am looking to enumerate files on directories that are not included in a library.

Anyone knows how this is possible in WinRT???

Was it helpful?

Solution

You are, by design, extremely limited in this area for Metro apps. The idea is that a Metro app is only given access to those things that it is trusted to access, so you can either:

  1. access local storage, specific to your application
  2. access a handful of well-known storage locations, or
  3. access a specifically granted location.

Take a look at http://msdn.microsoft.com/en-us/library/windows/apps/hh464959.aspx to get an idea as to what you'll be able to access.

OTHER TIPS

From http://tirania.org/blog/archive/2011/Sep-15.html :

When you use C# and VB, you are using the full .NET framework. But they have chosen to expose a smaller subset of the API to developers to push the new vision for Windows 8.

And this new vision includes safety/sandboxed systems and asynchronous programming. This is why you do not get direct file system access or socket access and why synchronous APIs that you were used to consuming are not exposed.

Now, you notice that I said "exposed" and not "gone".

What they did was that they only exposed to the compiler a set of APIs when you target the Metro profile. So your application will not accidentally call File.Create for example. At runtime though, the CLR will load the full class library, the very one that contains File.Create, so internally, the CLR could call something like File.Create, it is just you that will have no access to it.

This split is similar to what has been done in the past with Silverlight, where not every API was exposed, and where mscorlib was given rights that your application did not have to ensure the system safety.

You might be thinking that you can use some trick (referencing the GAC library instead of the compiler reference or using reflection to get to private APIs, or P/Invoking into Win32). But all of those uses will be caught by AppStore review application and you wont be able to publish your app through Microsoft's store.

You can still do whatever ugly hack you please on your system. It just wont be possible to publish that through the AppStore.

So there's probably no official way, and if there's an unofficial way, it probably won't be accepted to the app store.

Just in general this makes sense: I don't want to download a seemingly legit application just to have it scan my hard drive and find my "budget.xls" spreadsheet which includes my banking/credit information.

EDIT: it is possible to grant temporary access to secure files/folders through WinRT's file picker, but it has to be invoked and chosen explicitly by the user.

You can use the StorageFolder.GetFolderFromPathAsync Method to get a StorageFolder instance from a path.

StorageFolder folder = await StorageFolder.GetFolderFromPathAsync(@"C:\...");

Note that you may not have permission to do this for all paths on your machine though.

Similar situation. Wanted to access chrome bookmarks file to parse. Had to use FileOpenPicker initially, but the file that it returns can be "cached" in the futureaccesslist(?) for subsequent retrieval.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top