Develop Reference

C# user-defined application settings are not loaded on system startup

I have a C# WindowsForms application that uses Properties.Settings.Default to store application and user settings. Reading and writing custom user values works correct.
Application is set to automatically run on system startup or user sign on. Here's the problem: when the app starts on system startup it cant load any user-specific settings. They're all set to their default values. When i close the app and restart it - all user settings are back.
After debugging and logging i narrowed down the issue: on normal start application's working directory is set to the directory it was installed into. On system start (or user sign in) working directory is set to C:\system32 (or similar). That's when user settings are not loaded.
Is this a proper behavior ? If so, how would i correctly load (or reload) user settings?
NOTE: My application is deployed with ClickOnce so i can't really control where the settings file is stored. Also, i don't have any issues persisting the settings between the version upgrades.

Found a solution, although i'm not sure how "correct" it is.
In my application when user clicks on "Start on boot" checkbox option, i was writing the following into the registry:
string keyname = "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run";
RegistryKey key = Registry.CurrentUser.OpenSubKey(keyname, true);
key.SetValue("MyApp", Application.ExecutablePath.ToString());
The issue was resolved when i changed the app path to:
var startPath = Environment.GetFolderPath(Environment.SpecialFolder.Programs)
+ #"\Published\App.appref-ms";
key.SetValue("MyApp", startPath);
I think it has something to do with how ClickOnce apps are typically launched. I start the app using the desktop shortcut, not directly running exe file.

Access to registry seems to be different from different sources

I am trying to add a registry key in my C# code under
HKEY_CLASSES_ROOT\*\shell\blabla
I want the user to be able to send any file to my application, kind of like Open with UltraEdit or so.
I don't have administrator rights and the users won't have administrator privileges, too.
If I am doing that in my C# code as posted below, I get a
System.UnauthorizedAccessException
Registry.SetValue("HKEY_CLASSES_ROOT\\*\\shell\\blabla", null, "FastSearch");
string path = Application.ExecutablePath;
Registry.SetValue("HKEY_CLASSES_ROOT\\*\\shell\\blabla" + "\\Command", null, path + " \"%1\"");
If I run Regedit and attempt to do it manually myself, I get a similar error:
Error! Key could not be created. Error when writing to the registry.
BUT, if I double click a *.reg file that attempts to write the SAME KEY, everything works!
So why is that?
And do I have a chance to get this done through code?
Or should I just change my code to run that *.reg file?
UPDATE:
Actually the *.reg file did not write the SAME KEY as stated above, but
HKEY_CURRENT_USER\Software\Classes\*\shell\blabla
I didn't notice that. It seems as anything added under HKEY_CURRENT_USER\Software\Classes*\shell\blabla is also added to HKEY_CLASSES_ROOT\*\shell\blabla. Sorry for the confusion.

Although the problem is solved already and the reason for successful import of *.reg file was found out also in the meantime in comparison to C# code, here is a complete answer for this question.
HKEY_CLASSES_ROOT Key (short HKCR) as described by Microsoft shows file name extension associations and COM class registration information which are effective for the current user.
The real locations in registry for those keys are:
HKEY_LOCAL_MACHINE\Software\Classes (short HKLM\Software\Classes) containing the defaults for all users using a machine and
HKEY_CURRENT_USER\Software\Classes (short HKCU\Software\Classes) containing the user specific settings which override the default settings from HKLM\Software\Classes.
A registry write to HKEY_CLASSES_ROOT is always redirected to HKLM\Software\Classes. A write access to any key in HKLM requires administrative privileges which is the reason for the error message.
Microsoft recommends to write directly to either HKLM\Software\Classes or to HKCU\Software\Classes depending on changing the defaults or the effective file associations for the current user.
Write operations to keys under HKCU do not require administrative privileges.
HKCR should be used only for reading currently effective settings for file name extension associations and COM class registration information and not for adding or changing them.

WP8 copy SharedStorge file directly into IsolatedStorage

I am developing a Windows Phone 8 application but am having a lot of issues with file access permission exceptions hindering the approval of my application when ever I try accessing files in the "local" folder (this only happens after the application has been signed by the WP store, not when deployed from Visual Studio). To solve this I have moved all file operations to IsolatedStorage and this seems to have fixed the problems.
I only have one problem left though. My application needs to make use of the file extension system to open external files and this seems to involve the file first being copied to the local folder where after I can then manually copy it into IsolatedStorage. I have no problem in implementing this but it seems that a file access permission exception also occurs once the system tries to copy the external file into the local folder.
The only way I think this can be solved is if I can direct the system to directly copy into IsolatedStorage but I cannot figure how to do this or if it is even possible. It seems as if though the SharedStorageAccessManager can only copy into a StorageFolder instance but I have no idea how to create one that is directed into IsolatedStorage, any ideas?
PS. Do you think that the Microsoft system might be signing my application with some incompetent certificate or something because there is not a hint of trouble when I deploy the application from Visual Studio, it only happens when Microsoft tests it or when I install it from the store using the Beta submission method.
Below is a screenshot of the catched exception being displayed in a messagebox upon trying to open a file from an email:
EDIT:
Just to make it even clearer, I do NOT need assistance in figuring out the normal practice of using a deep link uri to copy an external file into my application directory. I need help in either copying it directly into isolatedstorage or resolving the file access exception.

Listening for a file launch
When your app is launched to handle a particular file type, a deep link URI is used to take the user to your app. Within the URI, the FileTypeAssociation string designates that the source of the URI is a file association and the fileToken parameter contains the file token.
For example, the following code shows a deep link URI from a file association.
/FileTypeAssociation?fileToken=89819279-4fe0-4531-9f57-d633f0949a19
Upon launch, map the incoming deep link URI to an app page that can handle the file
// Get the file token from the URI
// (This is easiest done from a UriMapper that you implement based on UriMapperBase)
// ...
// Get the file name.
string incomingFileName = SharedStorageAccessManager.GetSharedFileName(fileID);
// You will then use the file name you got to copy it into your local folder with
// See: http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.phone.storage.sharedaccess.sharedstorageaccessmanager.copysharedfileasync(v=vs.105).aspx
SharedStorageAccessManager.CopySharedFileAsync(...)
I've inline the information on how to do this from MSDN http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206987(v=vs.105).aspx
Read that documentation and it should be clear how to use the APIs as well as how to setup your URI mapper.
Good luck :)

Ok I figured it out. The "install" directory is actually restricted access but for some reason the Visual Studio signing process leaves the app with enough permissions to access this folder. The correct procedure of determining a relative directory is not to use "Directory.GetCurrentDirectory()" but rather to use "ApplicationData.Current.LocalFolder". Hope this helps!

Denied acces to a file

I have a code which is similar this:
string file;
using (StreamReader r = new StreamReader("xml.xml"))
{
file = r.ReadToEnd();
}
XElement xml = XElement.Parse(file);
using (XmlWriter w = XmlWriter.Create("xml.xml")) //The point of problem!
{
w.WriteStartDocument();
...;
w.WriteEndDocument();
}
When I try run it like a console application is everything all right. But problems start when I want to use it in an ASP.NET application. At the using line it throws UnauthorizedAccessException exception with a description "access to the path is denied". Why?

You need to check which account your application Pool is using to access your server files/folders, for example, make one code to copy one file to application folder, check all security info, copy and paste on this problem folder, normally use this account "IIS_IURRS" give full control to test only...

If IIS/the web server is configured correctly, an account with a very limited set of permissions is used. As your path points to the application directory, it is very likely that the application pool account is not allowed to write to this location.
If you run the code in a console application, your user's permissions are applied and it is more than likely that you are allowed to write to the output folder of the project as Visual Studio writes the build output there under your account.
I would not recommend to change the application pool account or the permissions of the application folder in the file system - it is a very sensible limitation that limits the amount of trouble an attacker can possibly make.
Therefore I'd recommend to either move the file to a folder that the account can write to without changing permissions or define a special one outside of the application folder hierarchy that the account is given permissions to.
Also keep in mind that multiple users might access the file at the same time, so a database might be a better choice to store the data.

Can't copy file with appropriate permissions using FileIOPermission

This snippet works well if I try to write in a user directory but as soon as I try to write in Program Files, it just executes silently and the file has not been copied (no exception). If I try to copy the file in C:\ or in C:\Windows I catch an UnauthorizedAccessException.
Do you know another way to get the permissions to write in that directory or to make it work another way?
Any help greatly appreciated! Thanks
using(FileStream fs=File.Open(source, FileMode.Open)){ }
try
{
FileIOPermission fp = new FileIOPermission(FileIOPermissionAccess.Write,
AccessControlActions.Change, "C:\\Program Files\\MyPath");
fp.Demand(); //<-- no exception but file is not copied
File.Copy("C:\\Users\\teebot\\Documents\\File.xml","C:\\Program Files\\MyPath\\File.xml",true);
}
catch(SecurityExceptions)
{
throw(s);
}
catch(UnauthorizedAccessException unauthroizedException)
{
throw unauthroizedException;
}

If you are running under Vista then the system just redirects writes to the program files folder, this is done so old program that keep their configuration in the program directory will continue to work when the user is not an Admin (or UAC is enabled).
All you have to do is add a manifest to your program that specify the required access level, then the system assume your program is Vista-aware and turns off all those compatibility patches.
You can see an example of a manifest file on my blog at:
http://www.nbdtech.com/blog/archive/2008/06/16/The-Application-Manifest-Needed-for-XP-and-Vista-Style-File.aspx
(the focus of the post is on getting the right version of the common controls, but the Vista security declarations are also there)

Don't write in the Program Files folder.
That's a big no-no, and will especially cause problems when the day comes where your code runs in Vista or on a machine at a company where users only get standard security rather than admin rights. Use the Application Data folder instead.

Are you running on Vista? If so then you may be running into file system virtualization. This is a feature in 32 bit versions of Vista which allows a normal user to write to protected parts of the file system. It's a shim introduced to reduce the pain of the LUA features of Vista.
The short version is that the operating system will create a virtual file system for certain protected roots (such as program files). When a non-admin attempts to write to it, a copy will be created an editted instead of the original. When your user account attempts to look at the file it will see the edit.s Other user accounts will only see the original.
Longer Version: http://thelazyadmin.com/blogs/thelazyadmin/archive/2007/04/26/file-system-virtualization.aspx

Code access security grants or denies permissions to your code.
It can't be used to override permissions that are granted/denied to the current user.