What is the difference between the magic paths in these namespaces:
Environment.SpecialFolder.LocalApplicationData
versus
Application.LocalUserAppDataPath
And
Environment.SpecialFolder.ApplicationData
versus
Application.CommonAppDataPath
etc...
They are not the same. The Application version of them is aware of ClickOnce deployment, adjusting the paths accordingly to keep them isolated.
On Windows 7:
Environment.SpecialFolder.LocalApplicationData = C:\Users\username\AppData\Local
Application.LocalUserAppDataPath = C:\Users\username\AppData\Local
Environment.SpecialFolder.ApplicationData = C:\Users\username\AppData\Roaming
Application.CommonAppDataPath = C:\Users\username\AppData\Roaming
Local is only ever stored on the local machine. Roaming is copied to the domain server (when in a domain) and is then loaded back onto other machines in that domain when you log on.
To add to the answer for anyone in the future who lands on this page, for all special folder related questions see the Microsoft's documentation which lists all the folder types:
Environment.SpecialFolder Enum
Related
i am trying to return all the files contain in a folder in UWP application for Windows 10, the code is shown below:
var path = #"C:\Users\Desktop";
var files = System.IO.Directory.GetFiles(path); //get empty arrays
But, i get empty string arrays, may I know what causes this problem?
You can't. For uwp and store apps, only the app installation and app temp folders are granted for direct access. 'Direct' means ... accesses without Windows.Storge broker process. (System.IO is 'direct'.)
If you want to access the 'outside' of your app - like as desktop, you need to ask user to pick the location by File/FolderPicker. Without the user interaction, you can't access.
However, Windows.Storage broker service provide the rich methods for file operation, and additional functions like as CommnonQuery features.
There are some exception for pictures, video folders, but the basic concept is same.
Following link may helps you. :)
File access permissions
Probably because C:\Users\Desktop doesn't exist on the system - it would be under C:\Users\YOUR_USERNAME\Desktop.
Additionally, your application might be operating in a sandbox, so all filesystem access will be virtualized to a private silo elsewhere - Windows would pretend that the directory you specified exists but says it's empty, because it doesn't want you accessing the user's files without prior permission.
Im trying to get the Users/Shared folder location in Mac so that i can write common user data(license) to it.I tried using
System.IO.Path.Combine (Environment.GetFolderPath (Environment.SpecialFolder.CommonApplicationData));
But its returning the folder in which I'm logged in.I know that i need to place the common application data in the Application Support folder but i think root privilege is required for this.If there is a better way to write to that folder,please suggest.
UPDATE:
I tried doing
File.Copy ("myfile.rtf", "Users//Shared//ll.txt");
But i get this exception >> Destination directory not found: Users/Shared
In OS X the directory is simply /Users/Shared, and it's directly off the root of the volume. There's no need to do Environment.GetFolderPath...
If you want to have user data or application data that can be shared by multiple users (read+write) you'll either want to create your own directory:
/Users/Shared/MyApp
and/or you can use:
/Users/Shared/Library/Application Support/MyApp
This way your application can share user data and application settings with all users. The /Library/Application Support folder (not to be confused with the one shared one), is owned by the system and anything that needs to write to it must obtain permission. The contents are read only, even for admin level users — something you'll want to consider when deciding where to store shared application data.
I am using Directory.Exists() in my windows service (that is programmed in C#, 3.5 framework)to check to see whether a particular directory exists in the drive. When I run in local machine it works fine, meaning I am able to access the directory.
But when I deploy the windows service on a Virtual Machine, and start the service, it is not able to find the directory even though the directory exists. The directory is mapped on as
Q: drive, Q:\\temp\\local\\ folder
But the windows services always returns false for the Directory.Exists().
However when I give C:\ drive in place of Q:\ it works, but does not work for a mapped drive. I have tried with the UNC path, and I have made sure the mapped drive have the administrative rights and infact the read, write and execute permission. But it still returns false.
Can anyone please tell me why? And how to resolve?
Make sure the drive is mapped under the same user as the Service is running. If you map the drive as user A, it is not automatically mapped for anyone else too.
Mapped drives are only restored during interactive login which services generally do not perform:
Map a network drive to be used by a service
Short version: You can't do it, use the full UNC path instead.
This is most probably a problem with privileges. Your Windows service is probably running under an account which doesn´t have enough privileges to access the network path.
This is a possible duplicate: Accessing mapped folder from a Windows Service written in C#
Another possible solution is to use impersonation, check it out:
http://msdn.microsoft.com/en-us/library/w070t6ka(v=vs.90).aspx
UPDATE
Came to think of it;
Try changing the identity of the application pool to a user with the same rights as your user.
As #Sriram pointed out the Directory.Exists() method will fail if any error occurs. What sort of exception do you get if you try to access the path?
Eg (for both mapped and UNC in case there is something going on there):
DirectoryInfo diMapped = new DirectoryInfo(#"Q:\temp\local\folder");
DirectoryInfo diUNC = new DirectoryInfo(#"\\servername\fnsw\tmp\126");
Note: Assuming that the white space before 'folder' in your path is a typo?
Steps to troubleshoot
Try accessing the network path manually in "Run" [WindowKey + R]
Try to access your map drive i.e.: M:\
Make sure you are the account owner of the mapping (mapping should be done under your account)
Go to Property and see if "Run As Administrator" is unchecked.
Remove mapping and re-add the mapping.
Make sure available offline (or sync offline) is turned off and folder is available from another computer.
Hope this helps!
Is there a way to set my app.config for my WCF service so that it outputs to the LocalApplicationData folder without having to hardcode anything?
%LOCALAPPDATA% does not work in XP, and I need to support XP
I have found that shell:Local AppData works, but I am not sure how to put this in an app.config
The next closest I can find is %APPDATA%, but I do not believe this is not the same as LocalApplicationData
Worst case, I can (but would prefer not to) use code to do this (using the SpecialFolders directly), but I am not sure how to set this while keeping the rest of the settings configurable?
You can get it from Environment object.
string path;
path = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
Edit according to comment:
Now i understand. You can create your own environment variables to use as part of path in your config.
CMD:
set mylocalapplicationdata="somewhere"
or C#:
string name = "mylocalapplicationdata";
string value = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
Environment.SetEnvironmentVariable(name, value);
After this you can use %mylocalapplicationdata% like other system variables.
You can set variable for one session (process), user, or machine (for machine you need admin permissions).
More information (MSDN):
http://msdn.microsoft.com/en-us/library/z46c489x.aspx
Alternatively you can use string like this:
%USERPROFILE%\Local Settings\Application Data
but this is for windows xp only.
I don't think there's a way to get the information you want using only built-in environment variables. The information is inconsistent from Windows XP to Windows Vista/7, so I think your best option is to update your config file during installation where you can determine the OS and access other Windows APIs.
I'm at the beginning of my project and I wonder which technology I should use.
In my little research I found WinRT API being kind of pleasant and I really like tile grid concept in UI.
The only problem is that my app will generate tons of data - important data - which I have to store somewhere on the local machine. By 'somewhere' I mean use of a different partition than the OS.
So, why not to try this simple code.
await Windows.Storage.PathIO.WriteTextAsync(#"d:\tests\test.txt", "Hello World");
Because E_ACCESSDENIED, that's why. Windows 8 slaps me in face screaming "Access Denied".
Is there any way I can store my data in a way I like or Win8 is too h4x0r proof?
And no, "Make a desktop application" is not a correct answer.
All you need to know about file access and permissions in Windows Store Apps.
First of all, when storing config data you have two options:
Windows.Storage.ApplicationDataContainer roamingSettings = Windows.Storage.ApplicationData.Current.RoamingSettings;
Which will use the roaming profile space so it will be stored in Cloud or Domain Profile
Windows.Storage.ApplicationDataContainer settings = Windows.Storage.ApplicationData.Current.LocalSettings;
Which will use the local profile space
Of course they both will be stored in the end under your users %appdata% but the roaming one will actually be synched if I understand everything correctly :)
So, for the application data that you would like to store on another partition:
First you need to select the location by using a FolderPicker
var folderPicker = new Windows.Storage.Pickers.FolderPicker();
//Add some other yada yada to make the picker work as needed
StorageFolder folder = await folderPicker.PickSingleFolderAsync();
Then you need to put the selected folder in an access list to remember that it's allowed to use this folder
StorageApplicationPermissions.FutureAccessList.AddOrReplace("PickedFolderToken", folder);
That way the application / system will keep track that it's allowed to use this folder in the future. The selected folder could be anywhere in the file system where you have access.
Finally if you wan't to get the selected folder back next time the app starts you simply do the opposite:
StorageFolder folder = await StorageApplicationPermissions.FutureAccessList.GetFolderAsync("TargetFolderToken",AccessCacheOptions.FastLocationsOnly);
The value FastLocationsOnly means that it will only return local drives. "TargetFolderToken" is the same identifier you used when you stored the folder in the FutureAccessList.