A little history may help clarify the situation. Back in the Windows 95/98 days all users had complete control over the system and access control over files/folders did not exist. When Windows XP was introduced it implemented the Windows NT security model and included access controls. The Windows security model is based on user identity, not on applications. In general, access controls allow or deny based on the identity of the user and are not tied to particular programs. To facilitate Windows XP adoption and make life easier for users that were unused to not having full control of and access to their systems almost all user accounts created in Windows XP were Administrators. This was a convenience for Windows XP users but created a significant attack surface for bad actors. Microsoft improved security when it introduced Windows Vista by introducing User Account Control. So although a user account was a member of the Administrators group in the ordinary course the rights allowed to that user would be those of a standard user account, not an Administrator. So the attack surface was reduced. A member of the Administrators group attempting to perform actions that required elevated Administrator privileges would cause the system to issue a consent prompt.
It appears that the security descriptor of the problematic folder does not allow a standard user to have write access (including changing the security descriptor of the folder). This is unrelated to your particular application. For example, you also wouldn't be able to save a file to that folder with Notepad. I haven't looked at the details of the posted code, but it must be executed with "Run as administrator" for Windows to allow changes to the folder's security descriptor. You can accomplish this when starting the related application or including a manifest in the application that specifies "requireAdministrator"