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???
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:
access local storage, specific to your application
access a handful of well-known storage locations, or
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.
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.
Related
I work for an IT company where we all carry around flash drives that have our most used programs on them.In my spare time I am hoping to create a "main menu" item that is kind of a fun and convenient way to access these files. I am working on creating this using Visual Studio 2013 and using visual C# windows forms. I have come across a snag however that I can't seem to find a workaround for. I am by no means fluent in C#, but I need to have a button on the windows form open a file without specifying what drive it comes from. I understand that I have to specify a path, but as these will be stored on the flash drives of myself and my coworkers I cannot foresee that the path will always begin with E:. Depending on what USB slot the drive is plugged into it could be N: or F: or the like. I have provided an example below:
Using what I currently know I am opening files using this line of code:
System.Diagnostics.Process.Start("C:/Users/Myname/Desktop/Asmodeus/Anti-Virus/Anti-Virus Installers/avast_free_antivirus_setup.exe");
Is there any way possible I can have the file open simply from
System.Diagnostics.Process.Start("Asmodeus/Anti-Virus/Anti-Virus Installers/avast_free_antivirus_setup.exe");
or something of that nature?
Thanks in advance.
There must have been some mis-communication when I asked my question previously. what I am looking to do is open an executable file via a button click on the windows form using a relative path. I am not able to specify the absolute path because the application will be run from a flash drive and therefore will change depending on what USB slot it is currently inserted into.
What I am hoping to accomplish is insert a line of code that will allow me to open an executable file that is located in the \bin\debug folder along with the application itself. I have a picture for clarification but apparently do not have enough reputation to post it. Thank you and sorry for the earlier confusion.
Usually you can just use Environment.GetFolderPath (MSDN) to give you what you need. It doesn't do absolutely everything, but if you need Desktop and the like, that is plenty.
Depending on the target version of .Net, the SpecialFolders exposed are not all there. It may turn out that you need more than they provide, but in your case it doesn't sound like it.
If there is more you need that is not covered in the default, check out this project. I'm sure there are others like it, but it does a little more than the default BCL version, using the API directly. It is at least something to read and learn (and translate from vb.. use an online translator, very quick). I haven't looked at it, but it seems like you are learning this c#/.net thingy, so it might be helpful
This article is about accessing Windows special folders.
These folders include your “Favorites”, “Cookies”, system libraries and the like.
Here is code, including a large number of constant definitions, plus documentation,
allowing access to and creation of these folders.
I have task to give in my application possibility to open document that is located on server, but I dont know at all how to implement this.
Please give the main idea how can i do this?
If you are trying to open a file based on it's MIME extension and not prompt the user, you really can't do that in a Silverlight web application (for either case, MIME launching or opening a file without prompting the user). Silverlight isn't a "browser standard", and a lot of it's seemingly crippled features are done so out of the name of security, and a safer user experience. (You don't want a Silverlight app randomly reading files on your hard drive without you knowing about it and silently uploading them somewhere now, do you?)
I believe you can do whatever it is you're trying to do in Silverlight 4, but it requires elevated permissions (and consequently that it must be installed out of browser), and a little bit of COM hackery.
The elevated permissions do not give you direct access to files outside of the "My" Folders, so I don't think you are going to be able to do what you want if you want to preserve cross platform compatibility to the Mac.
However, if you don't care about that, you can do just about anything you want regarding file access by utilizing the Windows system COM objects (specifically the WScript.Shell and Scripting.FileSystemObject objects).
Here's and example.
Scroll to the section of COM Interoperability.
Is there a standard way in .Net to access and modify the windows services file? Right now I'm just accessing the file via a stream and writing to the file like I would for any other file. The file is located in c:\windows\system32\drivers\etc\, but I'm worried that this may change in 64 bit versions of Windows or may vary in different versions of Windows (I could be wrong and admittedly, I haven't looked into this very much yet). Aside from that, I'm just wondering if there is a standard way, say via WMI and/or the System.Management namespace, to find and modify the services file.
The actual specifics of what I need to do is to check if certain database aliases used for our software are specified for the expected ports. If not, add them.
An open source project called System.Peppers has a class doing this.
There is a registry key that contains the full path to the files you are editing.
Here is a link to the exact class: HostFile class
Use the System.Management.Instrumentation namespace
Sample code here
http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=114
you can use System.Environment.SystemDirectory to get to the sys32 folder
for extracting special folder icons I'm using
ExtractIconEx(Environment.SystemDirectory + "\\shell32.dll",ncIconIndex, handlesIconLarge, handlesIconSmall, 1);
Here im passing explicitly nIconIndex for special folders like MyDocs,MyPictures ..etc
and its working fine in XP ,however in Vista its not retrieving the correct icons ..there it retrieves yellow folder icons..it should not be the case.
Cn anybody help me on this..
Vista added a new API called SHGetStockIconInfo but it does not support my documents AFAIK. But that does not matter since the method you SHOULD be using works on both XP and Vista (Your current solution will not work when the user has selected a custom icon, you are just looking in hardcoded system dlls, this could change at any point)
So, what you should do is, get the path or PIDL to the shell folder you are interested in (SHGetFolderPath and friends) and pass that path/PIDL to SHGetFileInfo. SHGetFileInfo can give you a icon handle, or the index into the system image list.
I'm not sure what the .NET equivalent for those functions are, but you should be able to figure that out, or use PInvoke
Check out the IconLib library at codeproject.
The best example I've seen of success in this area from .NET (and it was done with VB.NET) is in this article.
http://www.codeproject.com/KB/cpp/VbNetExpTree.aspx
My $.02 is that working with the shell API is extremely painful from .NET due to the level of COM interop required and the complexity of the API's.
One of my favorite things about owning a USB flash storage device is hauling around a bunch of useful tools with me. I'd like to write some tools, and make them work well in this kind of environment. I know C# best, and I'm productive in it, so I could get a windows forms application up in no time that way.
But what considerations should I account for in making a portable app? A few I can think of, but don't know answers to:
1) Language portability - Ok, I know that any machine I use it on will require a .NET runtime be installed. But as I only use a few windows machines regularly, this shouldn't be a problem. I could use another language to code it, but then I lose out on productivity especially in regards to an easy forms designer. Are there any other problems with running a .NET app from a flash drive?
2) Read/Write Cycles - In C#, how do I make sure that my application isn't writing unnecessarily to the drive? Do I always have control of writes, or are there any "hidden writes" that I need to account for?
3) Open question: are there any other issues relating to portable applications I should be aware of, or perhaps suggestions to other languages with good IDEs that would get me a similar level of productivity but better portability?
1) There shouldn't be any problems
running a .NET app from a flash
drive.
2) You should have control of
most writes. Be sure you write to
temp or some other location on the
hard drive, and not on the flash
drive. But write-cycles shouldn't be
a problem - even with moderate to heavy
usage most flashdrives have a life
time of years.
3) Just treat it
like's it any app that has xcopy
style deployment and try to account
for your app gracefully failing if
some dependency is not on the box.
If you want to use com objects, use reg-free com and include the com objects with your program.
You should always have control of your writes. Applications should be loaded into RAM at startup, and then memory past that is allocated in RAM, so nothing is written to the flash drive.
The most important thing for a portable application is that basically no installation is necessary for your application. You do not want to be dependant on registry values especially, since your application will not be 'installed' on other computers.
One of the issues with portable applications you may consider is data persistence. Generally, you write to a user's Application Data folder to save data. If this is the case, any data saved will only apply to the user on that computer. If you want some local application data, you may wish to create a Seralized XML file for your settings and store it locally within your application's directory. This file writing would then likely be the only write actions you'd need to worry about.
For your .NET portability issue, you could also write a small entry program in C++, which checks if the computer has .NET installed. .NET has registry values you can check to see the versions installed, so if .NET is installed, run your application, else display a message stating that .NET needs to be installed first.
Edit: I'd like to add that I do application development for Ultrasound machines using XAML in C# 3.0. The application I write works perfectly from a USB Flash Drive, while all user settings are stored on a local AppData basis, so nothing is written to the USB. While the application can be installed through an .exe installer, the installer does not write any registry values the application depends on.
I don't really have answers for #1 or #3. But for #2, the .NET CLR shouldn't be writing to an app's "installation" folder (i.e. the flash drive) unless your code specifically tells it to or is using and modifying file-based settings (ini, xml, etc) that live with the app.
Number 1 is really the kicker if you're not just writing things for personal use. Obviously hosting a portable copy of the full CLR on the thumb drive is impossible. But there are tools that can scan your assembly for its dependencies and package them up into a standalone .exe so that the CLR doesn't necessarily need to be installed on the target system.
I don't actually have any experience with this so it might be best to take what I say with a pinch of salt. But here is my take on it:
You don't need to do anything special.
It is not really a consideration of an application developer as to how and when writes are made to a drive, that is something that is far better controlled by the OS. I know that Windows caches writes to USB drives so I would trust it do handle that.
The only thing you need to consider is that your application will not be installed. So you need to make sure that you design it to run entirely self contained within the directory it is deployed to. You could optionally also make some writes to the users home directory but this needs to be done through the appropriate environment variables.
I would get writing and see if there is anything special about a flash drive that the OS doesn't handle.