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 Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
altenbach

Make application builder more compatible with google drive and similar tools.

Status: New

Using the application builder is problematic if the destination folder is monitored by syncing tools such as Google Drive (Backup&Sync), Onedrive, etc.

 

During building, there are tons of file operations in rapid sequence, potentially crashing the sync tools or causing false file conflicts (recent example).

 

To avoid these issues, I wonder if the building steps could be forced to take place in the temporary folder, followed by a final clean move to the destination. My guess this would make building more stable and compatible with external folder syncing tools.

 

8 Comments
N2STC
Member

Sounds reasonable to me.

MichaelBalzer
Active Participant

A workaround in the mean time would be a post-build VI to move the built application to a sync'd folder. My preference would be as a build spec option (a checkbox to use %temp%) rather than always use %temp%. Sometimes I need to see the contents of the build folder if a build fails.




Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
altenbach
Knight of NI

My LabVIEW development itself is on a monitored folder, simply because I develop on several different machines and most of my programs don't need external hardware (computations only). This way I can seamlessly continue working at home or while traveling. All my builds are done programmatically with a custom script does does a lot of moving, renaming, editing the ini, etc. all on a local folder, so I am good already. Here, I am trying to solve the problem of other users who accidentally build in a synced folder, where the build may fail and they might not immediately know why, blaming "bugs" in LabVIEW instead.

 

Of course there could also be conflicts if there are leftovers from a failed build in the TEMP location, so it should generate a random temporary root name for each new built (e.g. timestamp formatted in HEX). It could automatically open this temporary location in the file explorer if the build fails in some way, but clean it up if the build succeeds.

 

wiebe@CARYA
Knight of NI

If the synchronizing of the old stuff while building the new stuff causes the problem, a pre-build option might work just as good as a post build option, but without a temporary folder and move action. Clean the folder, make sure it's synchronized, continue... If that's possible, it would be far less hassle, AFAIC.

altenbach
Knight of NI

Synchronization is not the main problem. I've had the google drive actually crash during building of the exe. If you don't notice and reboot or restart the drive process manually, the sync will stop and none of your work will be available on other PCs as expected. It was explained elsewhere what the builder does.

BertMcMahan
Active Participant
DavidBoyd
Active Participant

No activity on this thread in two years, but this has been increasingly a problem for me as well.  Same situation as Altenbach - my project source is in a OneDrive4B-monitored folder structure so I can move between my development PC and a remote target where the hardware is present.  OneDrive instantly crashes if I build an exe within the monitored area.  I've taken to pausing and unpausing OneDrive around build operations.

 

The other OD problem (not LabVIEW's issue) is having to create junction points so I can keep <instrlib> and <userlib> folders synched across machines, since I'm doing some instrument driver and reuse code development outside of my project source space.

 

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
banksey255
Member

I have been experiencing this a pain for months with Microsoft OneDrive regularly crashing with the faulting module being kernelbase32.dll that I only recently associated with LabVIEW building an application, and can attest to it going unnoticed, particularly as the OneDrive icon remains in the system tray until the mouse hovers over it. My "solution", which isn't that elegant, was to create a batch file that has the following script that I have continually running that starts OneDrive then whenever it closes starts it again immediately:

 

@echo off
:start
start "OneDrive" /WAIT "C:\Program Files\Microsoft OneDrive\OneDrive.exe"
goto start