I was happily using log4net with my WPF program on an XP machine and happily using a fileAppender FileAppender to write log messages to c:\log.txt. All was well. However, it does not work on a Windows 7 machine. No error or anything, just that the file isn't created, much less logged to. A little research reveals that it's a file permissions problem (UAC) with Windows 7, and in fact it works if I run the executable as administrator. It doesn't work if I just click on it (even though I'm logged on as administrator) and it doesn't work when I launch from Visual Studio.
Questions:
1. Can someone point me to an example where I ask for permission to write to one and only one file (C:\log.txt). I've seen some examples of where the app.config is configured to ask that the whole program is run with admin privileges. This seems like overkill but I guess it would work.
2. Is there as better way to send the information to a log file? After all, perhaps C: does not exist on user machine. I think I recall the idea of a "user partition" in Windows 7, but whatever I do has to work on XP and Vista.
Thanks a ton,
Dave
You should not be trying to write directly to the root folder. Under windows 7, you will either have to run as administrator or disable UAC for that to work and neither are recommended.
Instead you can write to a folder in the 'application data' area
If you are using a .config file to configure log, you can use something like
<file value="${ALLUSERSPROFILE}\CompanyName\ProductName\Log.txt" />
or
<file value="${APPDATA}\CompanyName\ProductName\Log.txt" />
depending on whether you want the log files to be specific to a user or not.
(Obviously you replace CompanyName and ProductName with your own details).
This should work on Xp/Vista/W7.
You have 3 options in my eyes:
like mentioned always run your app as admin altough thats not a brilliant solution
Use the local path of the executing app to store your log - I always prefer this method as I always know where my logs are ( AppDomain.CurrentDomain.BaseDirectory will help you)
Use "My Documents" or some similar special folders - a quick google gives us: special folders
I hope this helps.
Related
I have a problem with my WPF application (a simple clicker game). I've just made a deployment/created a setup project using Microsoft Visual Studio Installer Projects extension for Visual Studio. Everything seemed to work fine, setup works good (tested on other computer) and furthermore the installed application almost works correctly. The only exception is a button calling function which is creating a new txt (something like a draft of a "save" file) file in a folder where the application is installed. Clicking this button cause instant crash of the whole application. Nothing else happens, no error message, the app just turns off.
I assume that the problem lies in access rights to the folder/administrator rights.
I've added txt file with the same name in the application folder using "File System" window in setup project, deployed and installed again. Even when the file exists the problem happend again (probably because of access rights when trying to override file content).
It's may be important that everything worked while running app through VS, also using .exe works fine on any computer. The problem is only with application installed using setup.
I'm not sure where the problem is so it's hard to show some code, to be honest i'm not even sure if it's a problem with code, maybe it can be solved with setting some setup project properties?
I would like to store some data locally between two sessions, i've choosed txt file because it's light and simple even if it's not the most elegant way.
I expect that installed application will be able to create and override txt file in it's folder.
P.S. if you need any code, screenshots or information about my setup please let me know in comments section, I will provide what's necessary
At the moment you install your program you're having administrator-rights. So the folder where your application is, also was created with administrator-rigths.
If you want to store data to this folder, you'll have to run your application as administrator. (not the best idea)
Otherwise you can change your code to write your file at runtime to a different location where you don't need administrator-rights.
For example:
string path = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
will give you: "C:\Users\MyUserName\AppData\Local"
string path = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
will give you: "C:\Users\MyUserName\AppData\Roaming"
string path = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);
will give you: "C:\Users\MyUserName\Documents"
And some error-handling around the saving of the file would be very nice and helpful ;)
Thank you everyone for solution and knowledge, the problem was as I assumed (access to the path denied).
I was using this code to create a path:
Directory.GetCurrentDirectory() + "\\SyntyhCitySave.txt";
Creating a file in a special directory instead of application folder works, that's the solution for my problem:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) + "\\SyntyhCitySave.txt";
Tomtom answer marked as accepted.
In my current project I like to use fopen or fopen_s to create a file via "w" option.
Using a QT GUI the user may choose any file name which is basically the return string of a file dialog - similar to what is known to windows dialogs.
QFileDialog::getSaveFileName(this,"Save as...","","all files (*.*)");
However, depending on the file name it gets created or not.
So for instance I can write files in my build directory 'C:/SVN/builds/GUI/temp.txt'
And I can create files on the windows desktop 'C:/Users/XXX/Desktop/temp.txt'
I can even create files in other build dirs 'C:/SVN/builds/foo/bin/Release/temp.txt'
But fopen doesn't let me create 'C:/temp.txt' and returns "access denied" (errorno 13)
my issue can be solved like described here: https://stackoverflow.com/a/4735652/2220850
but this effectively requires the user to have admin rights for my silly little tool to run properly.
so isn't there another way to get permissions to write the file the user selected from within the GUI?
Or is there at least for the user and me a way to know where on the disks our tool may or may not create files?
cheers
I don't think you can solve this in a clean way. There are folders that are forbidden to non-admin users. That's the way it is (without tweaking to OS settings).
Displaying your users a sensible error message like "Access denied (you may need admin rights to write to this directory, select a directory you may write to)" is probably the best way.
Read/write stuff where the shell/OS tells you you can/should do. Call the shell API to find out the correct path for Windows OS:
SHGetFolderPath()
SHGetKnownFolderPath()
I have created a winform application and programmatically trying to attach the database when an application runs first time. Unfortunately in windows 7 i always got an error. Please view the screenshot below it tells the whole story. Now my question is that how can i get rid from this error, is there any way to automatically give required rights on the folder where the application installs?. I want to permanently resolve this error and need smooth attachment. Anyone please help.
Please view the error below. Thanks in advance
Try ALTER DATABASE MyDatabaseName SET READ_WRITE
More informations here on This forum
Edit
This was asked by someone else
If you put your database in your own subdirectory of the directory returned by Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData then the user will have read/write access to it.
See Environment.SpecialFolder Enumeration to determine if a different location would be more suitable, e.g. ApplicationData if you need it to roam or CommonApplicationData if you need all users of the computer to use it.
Edit: I found a slightly more extensive version of this answer: Where Should I Store my Data and Configuration Files if I Target Multiple OS Versions?, please also see the articles it links to.
I know this answer is somehow late, but I believe people always face the same problems so my case is worth to be shared.
tl;dr = Change the permission of deployed files manually or using icacls command.
Actually I use InstallForge for packing and deploying my application(s).
No matter what setup creator is used, when the application is installed to a non-system folder ( e.g. D:\ ) the program works perfectly and the database is readable/writable.
Whereas when the application is installed in [Program Files] folder or [Program Files (X86)] folder, Windows takes a preventive security measurement and sets file permission to be only [Read] and [Read & Execute].
I think Windows Vista and later versions of Windows have this behavior.
You can check that by right-clicking the installed file and going to properties then Security tab.
The files I installed on D:\ had Full-Control permission while, as I mentioned, the ones on C:\ had only Read & Execute permissions.
You won't notice the difference when you install a normal program on C:\ because you might not be writing data on a file or a database. But in case of database deployment, the file has to be writable.
Finally, the solution for this case was telling InstallForge to change file permissions at the end of the installation using icacls commands :
icacls "C:\MyApp\MyDB.mdf" /Grant Everyone:F
icacls "C:\MyApp\MyDB_log.ldf" /Grant Everyone:F
In my case, it is okay to give everyone full-control on the database files, but you might need a customized solution for your case so please refer to :
http://ss64.com/nt/icacls.html
You can tell your setup creator to run those commands, or you can put them together in a batch file and run it after the installation.
Iam working on POS software using winforms. Iam trying to programmatically writing XML file (which contain some encrypted information about software serial number) to C:\Windows\System32 directory. But when i write i get an error Access denied.
Can anyone please explain how can i write this file with full permissions in this directory in windows 7 as well as in windows XP???
Any other suggestion or better way to do this will also be welcome.
Thanks in advance.
You'll need to be an administrator on the machine to write to the Windows directory. In addition, on Vista and later, your process will need to be "elevated" (otherwise known as Run As Administrator). You can configure this on your application's property sheet, as discussed here, or with a bit more work, do it programmatically.
It's bad practice to write to that directory, though, notwithstanding all the (misguided) software that does that. Save your files somewhere else. %appdata% or %localappdata% (directories specifically meant for application data) are good choices.
I've seen several questions that are the opposite of this; "How do I disable virtualization?" That is not my question. I want to force an application to run with virtualization enabled.
I have an application that ran just fine under Windows XP, but, because it writes its configuration to its working directory (a subfolder of "C:\Program Files (x86)"), it does not work completely under Windows 7. If I use task manager to turn on UAC Virtualization, it saves its config just fine, but of course it then can't load that config.
I do not want to set it to run as administrator, as it does not need those privileges. I want to set it to run with UAC Virtualization enabled.
I found a suggestion that I put some magic in the registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags. For completeness I also put it in Wow6432Node, but neither had any effect.
File system is virtualized in certain scenarios, so is your question how to still turn it on when your application does not qualify? It is unlikely possible, MSDN:
Virtualization is not in option in the following scenarios:
Virtualization does not apply to applications that are elevated and run with a full administrative access token.
Virtualization supports only 32-bit applications. Non-elevated 64-bit applications simply receive an access denied message when they
attempt to acquire a handle (a unique identifier) to a Windows object.
Native Windows 64-bit applications are required to be compatible with
UAC and to write data into the correct locations.
Virtualization is disabled for an application if the application includes an application manifest with a requested execution level
attribute.
this may come way too late now, but I am the author of the suggestion you found to activate UAC virtualization, and there was a mistake in my post. The registry keys to modify are the following:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
(notice the "Layers" appended)
so a full example would be:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="RUNASINVOKER"
note that multiple parameters must be separated with space character.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="WINXPSP3 RUNASINVOKER"
--
I'm sincerely sorry that you lost a fair amount of time because of my mistake.
And by the way, let me express my disagreement with Ian Boyd's post. There are places where write privileges should not be granted to everyone, such as this one, since it breaks the base security rule of "System-wide writes should be authorised to privileged principals only". Program Files is a system-wide place, not a per-user one.
All rules have exceptions of course, but in the present case, one could imagine a maliciously crafted configuration file making the program exec an arbitrary command as the user running it. On a lighter side, one could imagine a "mistake delete" by another user, which would make the app fail. Back on the heavier side, application executables in Program Files are often run by the admin, sooner or later. Even if you don't want to, uninstalling programs very often run uninstall executables that are in Program Files. Maybe the uninstall procedure will use that config file which could have consequences if it's maliciously crafted.
Of course you may say, this sounds paranoid somehow, agreed. I did modify some NTFS ACLs in Program Files at the times of Win XP and was able to sleep after that, but why take the slightest risk when the tools are available ?
I found one not very well cited condition where UAC Virtualization does NOT work: when the file in Program Files is maked as read-only.
That is, suppose the file C:\Program Files\<whatever>\config.ini is marked as read-only. When the application try to change it, UAC Virtualization will return an access denied error instead of reparsing it to %LOCALAPPDATA%\VirtualStore\<whatever>\config.ini.
Although I did not found this documented, this behavior is probably done by design, since it makes some sense.
The solution is simple: assure that all files that are supposed to be modified by the application are not read-only (or just unflag all files, since the user will not be able to change them anyway).
You have an application, and you want users to be able to modify registry keys or files in locations that by default only Administrators can modify.
If you were running Windows 2000, or Windows XP, or Windows Vista, or Windows 7, or Windows 8, the solution is the same:
grant appropriate permissions to those locations
For example, if your program needs to modify files in:
C:\Program Files\Blizzard\World of Warcraft
Then the correct action is to change permissions on the World of Warcraft folder. This is, in fact, a shim that Microsoft applied to World of Warcraft. (On next run it granted Everyone Full Control to the folder - how else can WoW update itself no matter what user is logged in.)
If you want users to be able to modify files in a location: you have to grant them permission. If you were a standard user trying to run WoW on Windows XP you will get the same problem - and need to apply the same solution.
Your application is writing its configuration to:
C:\Program Files (x86)\Hyperion Pro\preferences.ini
then you, in fact do want to grant Users Full Control to that file:
So your:
application is not set to run as an Administrator
users cannot modify the executable
users can modify Configuration.ini
Granting permissions is not a bad thing; it's how you administer your server.
There are two solutions:
Install to C:\ProgramData\Contoso\Preferences.ini and ACL it at install time
Install to C:\Program Files\Contoso\Preferences.ini and ACL it at install time
And if you look at the guidance of the AppCompat guy at Microsoft:
Where Should I Write Program Data Instead of Program Files?
A common application code update is this: “my application used to write files to program files. It felt like as good a place to put it as any other. It had my application’s name on it already, and because my users were admins, it worked fine. But now I see that this may not be as great a place to stick things as I once thought, because with UAC even Administrators run with standard user-like privileges most of the time. So, where should I put my files instead?”
FOLDERID_ProgramData
The user would never want to browse here in Explorer, and settings changed here should affect every user on the machine. The default location is %systemdrive%ProgramData, which is a hidden folder, on an installation of Windows Vista. You’ll want to create your directory and set the ACLs you need at install time.
So you have two solutions:
create your file at install time, and ACL it so that all users can modify it at runtime
create your file at install time, and ACL it so that all users can modify it at runtime
The only difference is semantic. The Program Files folder is mean for program files. You don't want to store data here.
And it's not because Diego Queiroz has any insight about security.
It's because it's where just the programs go.
Sometimes machines are imaged with the same Program Files over and over. You don't want per-machine data in your image. That data belongs in ProgramData.
And it's not a security issue.
Some people have to learn where the security boundary is.
there are quite some good points in those other answers.
actually i have upvoted all of those.
so let's all combine them together and add some more aspect ...
the OP mentions some "legacy application from the old days".
so we can assume it is x86 (32bit) and also does not include any manifest (and in particular does not specify any "requestedExecutionLevel").
--
Roman R. has good points in his answer regarding x64 and manifest file:
https://stackoverflow.com/a/8853363/1468842
but all those conditions don't seem to apply in this case.
NovHak outlines some AppCompatFlags with RUNASIVOKER in his answer:
https://stackoverflow.com/a/25903006/1468842
Diego Queiroz adds intersting aspect regarding the read-only flag in his answer:
https://stackoverflow.com/a/42934048/1468842
Ian Boyd states that probably you don't even should go for that "virtualization", but instead set according ACL on those files of interest (such as "config.ini"):
https://stackoverflow.com/a/12940213/1468842
and here comes the addtional / new aspect:
one can set a policy to disable all virtualization - system-wide:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableVirtualization"=dword:00000000
actually i'm enforcing this policy on each and every system that i own.
because otherwise it will lead to confusing behaviour on multi-user environments.
where UserA applies some changes and everything goes fine.
but then UnserB does not get the changes done by UserA.
in case some old crappy software fails then it should "fail"!
and not claim that everything went "fine".
IMHO this "Virtualization" thing was the worst design decision by microsoft, ever.
so maybe the system has this policy enabled and that's why virtualization doesn't work for you?
--
so probably the ultimate checklist would be:
is the application x86 or x64?
does the exe have a manifest (including the requestedExecutionLevel)?
have you checked the read-only attribute (e.g. of those INI files)?
is there a policy to force the EnableVirtualization to 0?
have you tried the AppCompatFlags with RUNASIVOKER?
or simply go for ACL instead of virtualization
--
in the end we are discussing how to get on old legacy application to run.
by using whatever workarounds and hacks we can think of.
this should probably better discussed on either superuser or serverfault.
at stackoverflow (targeted for programmers) we all know: it's about time to get all of our own programs compatible with UAC concept and how to implement things the "right" way - the "microsoft" way :)