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.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to make LabVIEW Installer put a configuration file into PublicDocuments folder

Solved!
Go to solution

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

 

0 Kudos
Message 1 of 6
(4,772 Views)

Place the file as a template in the program folder and copy it to Public documents at program start if there's none.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 2 of 6
(4,741 Views)

@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.....

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 3 of 6
(4,724 Views)
Solution
Accepted by topic author AnSche

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.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 4 of 6
(4,708 Views)

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

 

0 Kudos
Message 5 of 6
(4,702 Views)

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:

  1. From default context (no *.lvproj) <User\[username]\>\Documents\LabVIEW Data\  HINT: Use a Project silly!
  2. From the development project (MyProject.lvproj) <Project folder>\Data\ "Sweet"
  3. From the executable(s) built from the project <AppDir>\Data\

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! 

Capture.PNG

I just change the offending permissions before I access the config file! Smiley Surprised

Works like a charm! 

 


"Should be" isn't "Is" -Jay
Message 6 of 6
(4,691 Views)