Access to path denied while reading a dll from Program Files which is actually got from a nuget package

Asked 19/12, 2019 at 19:58 Answered 20/12, 2019 at 10:23

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.

Halogen answered 19/12, 2019 at 19:58 Comment(7)

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. – Nonsuit 19/12, 2019 at 20:0

@Nonsuit Could you please let me know how I could fix the rights issue for reading the DLL file that is in program files folder. – Halogen 19/12, 2019 at 20:2

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. – Nonsuit 19/12, 2019 at 20:4

@Nonsuit 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. – Halogen 19/12, 2019 at 20:5

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 we may be able to help you. – Aroma 19/12, 2019 at 20:21

@DourHighArch You are right, I'm just reading from Program Files. – Halogen 19/12, 2019 at 20:23

You can try to monitor your binaries with procmon.exe to determine what is going on: Hanselman shows the procedure in this video (about 3:50 in). I have a short-version procmon.exe sample here. 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. – Angara 20/12, 2019 at 0:5

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://mcmap.net/q/104334/-system-unauthorizedaccessexception-while-running-exe-under-program-files

Halogen answered 20/12, 2019 at 10:23 Comment(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. – Angara 20/12, 2019 at 10:57

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.

Nonsuit answered 19/12, 2019 at 20:30 Comment(0)