From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
03-01-2017 04:33 AM
Hi,
I have an application that uses a configuration file to save the last used state of the connected hardware. This information is not user specific, but has to be shared by all users in some public location where all users have write permissions.
The LabVIEW Installer only offers [Public App Data] as a possible destination. But there seem to be problems with file permissions in this folder.
I would prefer to use the PublicDocuments folder instead (c:\Users\Public\Documents\... on Win7). But the LabVIEW Installer does not offer any link to this system folder.
Does anyone know of a solution ??
Thanks
Anke
Solved! Go to Solution.
03-01-2017 05:25 AM
Place the file as a template in the program folder and copy it to Public documents at program start if there's none.
/Y
03-01-2017 06:23 AM
@AnSche wrote:
Hi,
[..]The LabVIEW Installer only offers [Public App Data] as a possible destination. But there seem to be problems with file permissions in this folder.
[...]
Anke
Seems that you have missed to create a subfolder. You are aware that you have to create subfolders to the destinations unless you define a new custom absolute path destination?
However, i concur with you that it would be nice if LV AppBuilder grants access to each System Directory. I refer to this term as the constant of the Get System Directory.vi defines.
My short investigations indicate that the AppBuilder restriction is connected directly to the MSI properties. So without further digging into this, i fear that LV AppBuilder cannot provide more predefined "base destinations" as MSI doesn't provide more by default.
As a workaround, you can include post-install actions (run executable after installation) to copy sources (similar to what Yamaeda recommends but only executed once with installation).
Another potential workaround could be to include command line options to the MSI. This however could require manual changes to the MSI after you created it using LV AppBuilder. I cannot tell you if this is feasible and really poses a 'good' solution.....
03-01-2017 07:36 AM
Further looking into and thinking about that request, i come up with the following thoughts and information:
1. Microsoft does not provide a default symbolic path in MSI for public user directory. Refer to this KB under the topic "System Folder Properties"
2. Microsoft does recommend the following installation guidelines:
a) Install application specific functional sources like the EXE or application specific DLLs to the [ProgramFiles] section
b) Install application specific configuration sources like configuration files and ReadMe's to the [PublicAppData] section
c) Install generic sources like common DLLs (used by other applications) into [System] section
d) Install user dependent sources like user specific configuration files into [Personal]
e) Generate link(s) to your application in the [AllUsersDesktop] section (or select the feature of MSI to automatically create shortcuts accordingly)
As you can see, the user specific data folder does not list in that recommendations.
3. Sadly, trying to move up folders in LV AppBuilder seems not to be possible. In fact, using '..' (or any similar logic) leads to a corrupt installation routine "Fatal Error. Unhandled MSI Error."
4. Trying to add new Destinations following Microsoft's Property names leads to a corrupt installer stating "TARGETDIR is not valid"
My personal recommendation, besides the already stated installation post action (custom EXE) to copy sources is to stick to Microsoft's guidelines and move to PublicAppDir instead.
03-01-2017 08:05 AM
Thanks Yamaeda and Norbert_B for your thoughts and experiments!
Norbert, you obviously tried the same tricks that I already had a go at. I got the same error messages as you (3.) and (4.) .
Thanks for the Microsoft recommendations. I did not find them as clearly written down as you did in your answer, so thank you very much for that.
I still am not very happy with the PublicAppDir as this is a hidden folder in WIN7.
Although ticking the checkbox Unlock in the installer's Source File Settings should grant write permissions to all users.
I think I shall provide a default configuration file with the application and in the same directory, and then let the application copy this default file to PublicDocuments if no configuration file can be found there. Thus the default file will be used directly after installation and whenever it might have gone missing.
Anyway now I am reasonably sure that I did not miss any important information. Thank you all for that.
Anke
03-01-2017 08:52 AM
I have a very unusual habit for avoiding those nasty file permission errors.
I simply stick the file in <AppDir>\Data\ Anyhow! spitting into the face of Microsoft's installation guidelines. I know, that is sort of "Naughty" but, as Norbert pointed out:
3. Sadly, trying to move up folders in LV AppBuilder seems not to be possible. In fact, using '..' (or any similar logic) leads to a corrupt installation routine "Fatal Error. Unhandled MSI Error."
4. Trying to add new Destinations following Microsoft's Property names leads to a corrupt installer stating "TARGETDIR is not valid"
Then we are back to only dealing with 3 possible file locations:
Since we use a project at all times for development this means we don't need to change the path build when we move from IDE to RTE. But, we are right back to Anke's original File Permission Error.
I wouldn't be wasting your time unless I did something about that!
I just change the offending permissions before I access the config file!
Works like a charm!