We are integrating the new Extract API into our Desktop tool to enable it to generate Hyper extracts.
We have found that it works fine when running in debug mode in visual studio, but when we generate our installer and install the application, we get an error.
If we run the application as administrator (right click and run as adminstrator) so that it has elevated permissions then we do not see the error and everything runs as expected.
What permisions does does the API need that are only available running as administrator? We do not see this issue with the previous TDE generation.
Is there a specific access that needs to be added in the setup project to ensure the installer grants the proper rights to the application?
UPDATE: I suspect that it is the log files being written that are causing the problem- these files are being written into the application folder, which the application itself does not have access to.
In the documentation, it states -
Optionally, you can set the following environment variables to specify working directories for the Extract API. If you don't set these variables, the Extract API uses the current working directory as the default location (TMP or TEMP on Windows and the TMPDIR on other systems).
Note: The user identity under which code is running must have write permissions to the locations you specify in these environment variables.
TAB_Extract API_LOGDIRThe folder where the Extract API writes log files.
TAB_Extract API_TMPDIRThe temporary directory where the Extract API keeps intermediate (temporary) files, such as when it's creating an extract.
I have tried to set windows environment variables using ;
Environment.SetEnvironmentVariable("TAB_Extract API_LOGDIR", logPath);
Environment.SetEnvironmentVariable("TAB_Extract API_TMPDIR", logPath);
However it does not seem to have any effect. Perhaps these are not windows environment variables but something within the SDK- I have not been able to find in the documentation how this should be done.
How should we set these variables so that the assemblies do not try to write into a folder where the user identity does not have access?