Access To Path Denied
-
Good People, So, my software installs a file that is read/write while the application is running. During debug, it works fine - read/write no problem. So, I created an MSI (Windows Installer Project in Visual Studio 2008 Sp1) for the application. It installs fine. However, now two problems have emerged: 1) It states that access to the path where the file is located has been denied (it's nested in Program Files). 2) I tried to uninstall it but it's telling me that the appropriate level of access to the registry (something about HKEY_CURRENT_USER roots, certificates, blah, blah...) is not present. Any help you can provide would be great. (What really irks me is that when I created the install project before, I never had this issue. I bet it's some setting I missed. Oh well.) Thanks, Blitz
-
Good People, So, my software installs a file that is read/write while the application is running. During debug, it works fine - read/write no problem. So, I created an MSI (Windows Installer Project in Visual Studio 2008 Sp1) for the application. It installs fine. However, now two problems have emerged: 1) It states that access to the path where the file is located has been denied (it's nested in Program Files). 2) I tried to uninstall it but it's telling me that the appropriate level of access to the registry (something about HKEY_CURRENT_USER roots, certificates, blah, blah...) is not present. Any help you can provide would be great. (What really irks me is that when I created the install project before, I never had this issue. I bet it's some setting I missed. Oh well.) Thanks, Blitz
Hi, for 1) I am not surprised; you probably needed admin privileges to get your app installed (so all users can use it), however a regular user cannot write to Program Files and its descendents. Furthermore, one could make the whole app folder (or even Program Files) read-only for added protection, so the user trying to write files there is no good. I suggest you use one of the preferred file locations using the Environment.GetFolderPath() method, probably with the SpecialFolder.ApplicationData or .CommonApplicationData parameter. You can creaye subfolders and files in there as much as you need to or want to. Mind you, the actual path returned by GetFolderPath will depend on the specific Windows version, and some admin choices made while installing Windows; however the method takes care of all that. for 2) I have no idea. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
Hi, for 1) I am not surprised; you probably needed admin privileges to get your app installed (so all users can use it), however a regular user cannot write to Program Files and its descendents. Furthermore, one could make the whole app folder (or even Program Files) read-only for added protection, so the user trying to write files there is no good. I suggest you use one of the preferred file locations using the Environment.GetFolderPath() method, probably with the SpecialFolder.ApplicationData or .CommonApplicationData parameter. You can creaye subfolders and files in there as much as you need to or want to. Mind you, the actual path returned by GetFolderPath will depend on the specific Windows version, and some admin choices made while installing Windows; however the method takes care of all that. for 2) I have no idea. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
Thanks Luc, I will use the strategy you suggest.
-
Thanks Luc, I will use the strategy you suggest.
you're welcome. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.