I've read a bit that putting a.NET 2.0 SQL CE database in the program files directory where the application is installed is a bad idea. I'm running into the following error:
Access to the database file is not allowed. [ File name = C:\Program Files (x86)\MyCompanyName\MyApplicationName\MyCEDatabaseName.sdf ]
So I've heard, put it in Common Application files.... I'm not sure where that is, and I've read that the installer may drop the file there with the same permissions. I've also read that people have moved their file there and had issues.
Is it possible to change the ACLs of the file in the program files directory when the installer drops it there? I already have hooks into the application from the MSI to collect and set configuration options. I haven't found a good example of how to change the permissions on ONE file.
Then I've read to store it in the user's application data, but if you're installing the application 'for everyone' where will the file go?
Thanks for your time.... confused.
I assume you are using a MSI package. In this case you can use CommonAppDataFolder which is resolved to "C:\ProgramData".
However, this is also a per-machine location, so it requires the same privileges as Program Files. I think you heard about Application Data folder (AppDataFolder) which is a per-user location (something like "C:\Users\\AppData\Roaming"). It doesn't have permission problems.
If you want to use a per-machine location a solution is to use the LockPermissions table:
http://msdn.microsoft.com/en-us/library/aa369774(VS.85).aspx
This is a bit complicated because of all the permission flags. So if your setup authoring tool doesn't offer support for setting permissions, I suggest a simpler approach: use xcacls.exe as a custom action:
http://support.microsoft.com/kb/318754
This way all users can gain access to your database file.
Related
I am trying to help port a .Net service to a more modern .Net version (possibly Core) and use the MSIX installer. The application has several configuration files generated by the compiler (in source they are app.config but compiled they become *.exe.xml), they are installed into Program File right next to the binaries and a GUI helper app as well and the application itself can modify them to change service behavior (port, ip, tls cert, etc).
Writes under C:\Program Files\WindowsApps\package_name are not allowed.Writes under C:\Program Files\WindowsApps\package_name are not allowed.
The problem I am facing is that the MSIX installer makes it so that files in it's sandboxed version of Program Files cannot be written to (see above). That means that this application cannot be configured, so I am trying to figure out not only how to make the app configurable again, but also how windows wants to handle app configuration.
Right now it seems like there is two general approaches to do this:
write the configuration data to the service account's AppData/local folder
try to mimic a /etc/Myservice behavior in another folder. (meaning a local system-wide directory that houses configuration data for the service)
If you suggest #1 please answer the following additional questions:
How would I move Application configuration files to a user configuration file directory
how can an admin with a normal account modify the config file in the Service Account's AppData folder with the mentioned GUI helper application? (do they need to enable desktop access to the service account, login and run the GUI)?
If you suggest #2:
Where would you suggest this directory exist (specifically where will MSIX allow it)?
How do I tell the .Net application that the files are not right next to it? Can I just use AppData.CurrentDomain.SetData?
Well, a service running on the system account is the same for all users, so I would say that CommonApplicationData is a better folder for storing its settings, instead of appdata. This folder is easily accessible to both your service and to any admin that needs to deploy a custom config file.
In AppData you should store only actual user files (like files or settings generated by the actions taken inside your app by a specific user - thus different files for different users).
Now, the second part is where you need to configure you code to load the config file from a custom path instead of looking for it next to the EXE. I am no .NET expert but after a quick search I found this:
Relocating app.config file to a custom path
The modern approach to deploying app customizations
What is not clear to me is how your customers use the GUI helper tool to customize the config file. Is this just a tool that is used by someone from the IT department to generate the config file, and then they would copy that file and deploy it to the end-user machines using an MSI/MST file (or through some other custom deployment method)?
If your application is only deployed by IT folks, then you can try another simpler (and much elegant) solution for providing it with a custom config file, which actually doesn't require any code changes.
You can still leave the config file next to the EXE, in ProgramFiles and instruct the IT teams that deploy the app to use an MSIX Modification Package to deploy the custom config file generated by your GUI helper. (check the link included above for an example - with a video version at the end of the article).
Note: IT teams can use multiple free or paid tools to generate MSIX Modifications Packages.
Of course, your GUI helper tool still needs to generate that customized config file in a folder where it is allowed, as it can no longer write under ProgramFiles. So actually, you do need to modify a little bit your code in this scenario too.
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 developed a little software for Windows few weeks now and got problems when trying to make proper installer for it.
I got spesific request that database file has to be in same folder where program is so user can take own backups every now and then.
When I install it (using Visual Studio 2012 and InstallShield Limited Edition project) it works in my main computer(W7 64-bit), my laptop(W8 64-bit) and my buddys Laptop(W8 32-bit) just fine.
My main computer runs program as it should, it uses database file from programs Database -folder(C:/Program Files (x86)/Program Name/Program Name/Database) and doesnt create additional db files but my laptop and my friends laptop create folder to
"C:/Users/User/AppData/Local/VirtualStore/Program Files (x86)/Program Name/Program
Name/Database" and use database from there.
Also I noticed that program crash on start on my other test computer that runs W7 32-bit and I made sure that .Net Framework was installed.
Connection string goes like: sqLiteConnection1.ConnectionString = "data source=.\\Database\\db";
Program's Platform target is set to Any CPU and it uses .Net Framework 4.5 if that helps anything.
Any ideas whats causing this and how I can fix it?
database file has to be in same folder where program is so user can take own backups
Danger Will Robinson! Non-admin users cannot modify files in the shared or Program Files folder. You are forcing users to run as Admins, or change the Program Files folder so non-Admins can modify it; both are serious security vulnerabilities.
If you install the database to the Programs folder, then the database is part of the install and not user data. This means that repairing or uninstalling the application will delete all user data. Users don't like that.
Your application should copy the application database to a user folder like Environment.SpecialFolder.ApplicationData and save all changes there. All users can modify and backup data from their own folders, no security vulnerabilities required. Also, when someone repairs or uninstalls the application, all users get to keep their data.
Your connection string is using current directory (.).
Create it dynamically with Assembly.GetExecutingAssembly().Location.
I have an Application in WinForms,
I have created SetupDevelopment project and then install an application using Setup.exe file
i have added MSAcceess db file into application folder file,
when i install an application the database file gets readonly. how can i make file writtable after installation?
I found some solution on internet and found that when i tried to install application in different path other than "C:\ProgramFile\" and make application available to all user,it solves my Problem, but i want to install an application only in "C:\ProgramFile\" and want to available to only "Current user"
how can i achieve my Problem ?
In modern Windows Operating System the folders 'Program Files' or 'Program Files (x86)' are read only for the common users. This choice has been done for security reasons and you cannot easily bypass this rule. The reccomended folders, to use just for the current user, are C:\users\username\AppData\Roaming or C:\users\username\AppData\Local identified by the Environment.SpecialFolder.ApplicationData or Environment.SpecialFolder.LocalApplicationData. To this base folders add another subfolder identifying your application or company and install your database there.
If you want your database available to all users of the current PC, you could install it in the Environment.SpecialFolder.CommonApplicationData that resolves to C:\programdata. (Again, adding a subfolder specific for your application or company)
Again, don't try to force the operating system to work against its rules. You will find yourself in trouble very often.
I am using inno setup to make a installation package for my application, and my application is written by C# + .Net 2.0 + VSTS 2008. Inno setup => http://www.jrsoftware.org/isinfo.php and I install my application under Program Files/Foo folder (Foo is my application name). My application is targeting to Windows Vista.
The issue I found is my program cannot write to the folder Program Files/Foo. And I need the permission of write to this folder in order to save some configuration files. The strange thing I notice is the folder Program Files/Foo is marked as readonly and I have checked all folders under Program Files are marked with read only, such as Office.
My questions are,
Why all folders are marked as read only under Program Files? It means we should not write to individual application folders under Program Files? If not, where should we write information to disk like user last selected configuration information of an individual application?
If we could write to individual application folders under Program Files, what is the solution? I do not want my application to Run As administrator to solve this issue, and if there are solution to write to this folder, I want to require minimal permission if possible.
You should write user specific config data to the Application Data folder for the current user, using the special folders enum and the Enivronment.GetFolderPath.
Best Practice is to not store config data in the Program Files folder. Instead, store your application's data in %AppData%\YourApplicationName. Depending on whether you want to store your config data per-user or in a shared common folder, use one of the following enums to get the folder path:
string userAppData = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
string commonAppData = Envrionment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);
By default, Vista users do not run programs as Administrators and hence those programs have only read access to the folders under "Program Files". Users can change this behavior by disabling UAC and you could ask your users to do that, but in an office setting users might not have that option. That's why you use AppData instead -- applications can always read and write data to the AppData folder.
Information on UAC can be found at Microsoft's site. Although this page is fairly long, it's a starting point for understanding UAC:
http://msdn.microsoft.com/en-us/library/bb530410.aspx
A common solution would be to install configuration files to the Application Data folder i.e. like follows:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)