My WPF application writes an XML file to a folder within the CommonApplicationData folder on a Windows 7/64 machine. This works fine from Visual Studio 2010. When running from the .EXE file, I get a System.UnauthorizedAccessException when writing the file.
Is this a problem with my initial setup of the folder? Or is this related to the permissions of the executable file itself? Not quite sure how to handle this one??
Paul
I think that it is a problem with permissions to the folder.
Probably Visual Studio runs your application as an administrator and the .EXE file is executed as a normal user.
Perhaps you want to re-evaluate storing that data (XML) in that location all the time. Limited users won't be able to write to it. Sure, you can force admin privs but your users may not always have that option (and it's kinda a hack anyway).
The question below seems to outline a work-around depending on the user's priv level.
writing files to Common Application Data folder denied
Right click on the *.exe file and "Run as administrator".
Related
Access to path denied error is encountered in Program files (x86),
while working with a DLL that is got from nuget package: AODL for reading ODF files - https://www.nuget.org/packages/AODL/ after I created a MSI file using SETUP Project
In the code, I don't suspect the file creation part for I create this file in the user chosen file conversion path but NOT IN PROGRAM FILES folder path:
File.WriteAllText(targetFileName, sb.ToString(), Encoding.UTF8);
That's why I simply suspect the DLL, please let me know how I could find the error and fix this.
A bunch of directories - both Programm Files, the root directory of the System Drive, Windows - are heavily protected by NTFS rights. Writing them is usually a plain "no-go". Unless you run around with full administrative rights - wich only Instalers and very rare Adminsitrative tools should even consider - you will not be able to write there.
However you indicated this happens on a read. Reads being blocked like that is very unusual. You need to check what rights are set on those folders and why. Maybe the installer accidentally copied the rights from your computer, wich only makes sense with your users and groups? Maybe Windows or a third party broke those rights? Not a lot of options I can think of that could apply here.
For this application, even for reading the DLLs from the Program Files folder I needed Admin rights so I forced the application to have such rights for execution.
The below line for the newly created application manifest file is changed and that solved the issue.
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
The fix is explained well in How do I force my .NET application to run as administrator?
The reasons are stated well in https://stackoverflow.com/a/50588465/129130
I have a C# winforms application which will not work once installed to the C:/ProgramFiles folder. I use an MSI created with Wix to install. When either double clicking the exe or right clicking and running as admin this window pops up and then nothing happens:
Application Error Message:
The application works in Visual Studio and when accessed via the bin/Debug folder of my VS project (the exe in the Debug folder is the one I am using for the Wix install).
After the MSI installs, if I copy the exe out of
C:/ProgramFiles to one of my user folders (ex: C:/Users/User/Desktop) the exe works.
I am guessing this is some sort of UAC/permissions issue but I cannot find any documentation to confirm that theory. Any direction would be much appreciated.
EDIT:
Looking at the error log it is denying me access to my config file. Here is the error text:
Access to the path 'C:\Users\*username*\AppData\Roaming\Leer Copy\leerConfig.xml' is denied.
EDIT II:
This problem is getting more confusing (and frustrating). It will allow me to write to the AppData folder but not read from it (shouldn't it technically behave the other way around?)... Would really appreciate some help. I am reading the contents of my XML file via XDocument.
Originally had hid the config file so people do not mess with it/accidentally delete it. Making the file not hidden fixed the access denial and everything works how it should now.
I have a program which stores different things such as reports, products etc. and relys heavily on reading and writing to text files.
I have used Visual Studio Installer to turn the program into a .MSI file using the set up wizard. When asked if there are any extra files, I did add all the text files.
However, I cannot write to them. I seem to be able to read them, however if I try to delete anything in the files, or add something to them I get accessed denied.
I went through all the text files that had been installed, and changed them so the user had full permissions, however this does not seem to have helped.
Does anyone have any idea why this may have happened?
Thanks
Lucy
You are probably storing those files in Program Files folder, i.e. where the application is installed. This folder requires admin rights to write inthere.
Read more about the correct way and locations where to store user and application data.
First off hi all, and thanks for the many times searching here has helped me out or taught me something.
I've made a custom HUD for a game I play, and am working on an installer in C#, inspired by another HUD for the same game. It downloads and overwrites all the script files to the existing directory:
C:\Program Files (x86)\Steam\steamapps\me\team fortress 2\tf
[I don't have any control over which folder to use unfortunately, since I'm modifying files which Valve installed]
In order to delete folders, add folders, or copy files, I've had to use an app manifest to increase the user permissions every time the exe is launched:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Somehow, the installer I've been inspired by is installing to the same folder that I am, without forcing a UAC prompt.
His app only shows a security warning, but if I uncheck the "always check" checkbox, I can run it over and over again without having to verify any special permissions:
http://www.trishtech.com/img_art_a/win7_publisher_not_verified_0.jpg>">
Any suggestions on how I can make my app more seamless like his? I've contacted the author of the other app, and he says he is also using C#, but doesn't know of anything special he's doing to make this work.
EDIT: A few things I know we're doing differently, just in case they make a difference somehow:
I'm using a file browser to decide where to put my files, so the app can be run from anywhere.
He's just outputting them to the same directory as the exe, requiring the exe to be put in the destination folder.
I'm using ILMerge to bundle SharpZipLib with my app.
He's just leaving the dll in his zip file next to the exe.
If you are trying to write to "C:\Program Files (x86)" then you need admin rights. It follows that the other app must not be creating files there, but to a directory that is not protected by UAC.
If your files are per user, then you can create a subfolder in the appdata folder and save the files there.
Convention is to create a folder to indentity the company and another to identity the product,
eg
var dir = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
+ "\\MyCompanyName\\MyApplicationName";
He's just outputting them to the same directory as the exe, requiring the exe to be put in the destination folder.
I don't think that will be it. The same exe directory should be no different, you either have permissions or you don't.
The "normal" response would be, write to a directory you have permission to. But this is not always possible.
If you ran your application as a service it would popup just the once I think under Windows, but this does not seem right for your use case.
I don't think there will be any proper way to suppress such a message, its like a catch 22 situation. To do something you cannot do, you need to get permission (so elevate user -> UAC popup).
I'm marking sgmoore's answer as the right one, although my own case seemed to be something a bit stranger and I want to document that too.
I've stripped down my program to the basics and done a lot of experimenting. I figured out that for some reason, he and I actually can copy files and create folders into that directory. Maybe it's something special about the steamapps folder, or maybe it's just a bug that's making it actually work in this limited case, when it shouldn't normally for "real" programs.
What was actually requires the UAC prompt, strangely, was running the exe from the \Bin\Debug\ folder where my project was initially generating it. If I move my exe somewhere else and then run it, it works fine. If I run his exe from my \Bin\Debug\ folder, his doesn't work either. I haven't been able to figure out why that is.
Something else I noticed is that when my app is going to succeed without an exception, it doesn't prompt with the security warning when I launch it. It just silently opens and then works. Any time it does display the security warning, it fails.
I guess the protocol would be to turn those two issues into new questions, but it seems at this point it's probably well into edgecase/hack territory since all of you agree that this shouldn't even be working at all.
I'm going to build my program back out and see if I can still get it to work with full functionality under these weird circumstances, or whether I'll have to reenable the UAC elevation.
I have created a windows application setup program, it needs to have a text file in the application folder. The file is also included while creating the setup.
Once the setup successfully completes and my program tries to modify the file based on user input, its simple throwing an exception.
I am using Windows 7 Home Premium OS.
Any suggestion/help will be great to overcome this issue.
This is normal on a Vista or Win7 machine. Or a properly secured XP machine for that matter. The normal install location for programs, like c:\program files\your company\your app, is read only for most users. UAC is a counter-measure to malware messing with programs.
You'll need to store the text file into a writable location, the AppData folder. In the Setup project, right-click "File system on target machine" and select User's Application Data Folder. Find that file back at runtime through Environment.GetFolderPath, passing Environment.SpecialFolder.ApplicationData. Or use "User's Personal Data Folder" if the user should be able to find it back easily through the Documents folder.
What exception is being thrown? It could be a UAC issue.