C# Winform Application Only Working as Run as Administrator

Question

I am working on a application which is Windows Form Application and performs the CRUD operations in Microsoft Access Database (.mdb).

Old application: The application was developed in C# with Microsoft.Net Framework 4.0.

The previous developers used Visual Studio installer projects to create the setup file. The default installation path is "C:\Program Files (x86)\MyProduct".

This folder will have the MyProduct.exe executable and dependent dlls and also and Microsoft Access database file (.mdb). The shortcut will be created on desktop. When you run the MyProduct.exe it can access the database without any errors and can perform the CRUD operations.

---

New Application: Now I have upgraded the.Net framework to 4.5.2 and used Installshield to create the installer. Installation path will be same "C:\Program Files (x86)\MyProduct".

Now the problem is, when I execute the exe and do any insert/update/delete operation it throws the error that "operation must use an updateable query". This means the database is not accessible. I tried running the exe as an administrator user and then only it is working fine.

My operating system is Window 10.

Note: I modified the database.mdb properties and provided FullControl to all the users for both new and old versions. But new version is not working without the admin user.

For the newer version I changed the installation path to "C:\My Folder\MyProduct" and it is working without any error. Only C:\Program Files is giving the error. The strange thing is older version is also installed in Program Files but it does not throw any errors.

Other difference between old and new application is, Older version uses Microsoft JET engine driver to use Microsoft Access database, while newer version uses Microsoft ACE OLEDB driver to use Microsoft Access Database.

I am not sure why this is happening. Older version is working but newer is not. Can any one help me with this?

Answer 1

I would move the install to %userappdata% or some folder that does not require elevated rights. While you can place the.exe in program files, ANY data file in those locations tends to have VERY limited rights these days (they continue to lock down windows more and more).

Also, be carefull. Even if you say installed to my docuemnts? If you REQUIRE elevated rights during that install, then of then often DURING the install then the files and folder you create ALSO will have elevated rights.

So, don't place ANY data files or files that your code has to read in program files. These days such system folders tend to be restriced and have locked down rights.

%appdata% is your best bet. That will in most cases translate to:

C:\Users\AlbertKallal\AppData\Roaming

This ALSO means that your code better not have hard coded path names either. (you get/grab your path from the executing assembly. If you have a lot of code, and paths are hard coded? Then you can bite the bullet and say install to c:\MyCoolApp or some folder you create in the c:\ drive. However, with so many people doing remote work, then even c:\SomeFolder can be a bad choice, since on terminal services, all users share the same c:\ drive.

So, move the install out of program files, or at the very least move out the data file parts to a known read/write folder that all users by default will have rights to, and not require elevated rights to use such folders. So, be very aware of any data file parts you have as part of your install. As noted %appdata% is a good choice, but then keep in mind that the path names to the executable and the data file location will be dynamic (the users name will be part of the path name). And if you don't think you ever support terminal services or remote desktop? Then you can use/risk a hard coded c:\MyApp folder approach here.

At the end of the day, you REALLY need to avoid elevated rights DURING the install, and this is especially the case if data files are part of the install - since those files will ALSO inherit the elevated rights during the install. And for sure using program file which was common 10 or 15 years ago for programs AND data? Well the program part is still ok, but any data files now can't for all practical purposes be placed in program files.