0

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

enter image description here

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.

John
  • 533
  • 1
  • 8
  • 25
  • Ar you trying to write the file into a Programm directory? This is very likely to fail due to the rights limitations. If you do not try to write into Programm Files of all folders, this is likely the attempt to read teh .dll itself - fails for the same rights reasons. – Christopher Dec 19 '19 at 20:00
  • @Christopher Could you please let me know how I could fix the rights issue for reading the DLL file that is in program files folder. – John Dec 19 '19 at 20:02
  • You could run the programm Fully elevate, however that is not a good idea. Are you allowed to deploy those .dll files with your programm? If you are, just have a copy in the output directory. | However it is worth point out: While *write* rights to that folder are extremely unlikely, reading should still be fully possible. – Christopher Dec 19 '19 at 20:04
  • @Christopher Yes, I have a copy of the DLL in the output directory which is eventually copied to Application Folder by MSI file created by a Setup project that actually creates the windows installer. – John Dec 19 '19 at 20:05
  • Only the installer should write to the Program Files directory; letting a third-party DLL do that opens massive security holes. If you [explained why you think you need that](https://meta.stackexchange.com/questions/66377/) we may be able to help you. – Dour High Arch Dec 19 '19 at 20:21
  • @DourHighArch You are right, I'm just reading from Program Files. – John Dec 19 '19 at 20:23
  • 1
    You can try to monitor your binaries with [procmon.exe](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) to determine what is going on: [Hanselman shows the procedure in this video](https://www.hanselman.com/blog/HowToUseProcessMonitorAndProcessExplorer.aspx) (about 3:50 in). I have [a short-version **`procmon.exe`** sample here](https://stackoverflow.com/a/47792474/129130). You will see failed access and all kinds of stuff. And slightly related, I also have [this old summary of access denied issues and potential fixes](https://stackoverflow.com/a/50588465/129130). – Stein Åsmul Dec 20 '19 at 00:05

2 Answers2

1

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.

Christopher
  • 8,956
  • 2
  • 14
  • 31
0

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

John
  • 533
  • 1
  • 8
  • 25
  • 1
    You might want to raise that as a concern for the developer of that package? Running with elevation is not good at all, but it should work. – Stein Åsmul Dec 20 '19 at 10:57