Mass compiler: Could not load (*) because (*) in memory.

[MimiKLM]

Quick one:

What cause and how to avoid the Could not load (C:\NumericLimitLabVIEW\labview.vi) because (C:\DefaultLabVIEW\labview.vi) in memory. message during the maas compiling?

Renamig files won't be solution.

[TCPlomp]

I don't think that the mass compiler of NI tries to load multiple VIs into memory.

However I have to warn you not to use the Mass compiler, it might recompile Vs you don't expect.

Sorry I can't really help you,

Ton

[Hillman]

Hi MimiKLM,

Good Morning and I hope your well today.

I was wondering if this issue was still a problem?

Can I ask why you were mass compiling this directory? 

Like TonP you don't really want to use this to much. 

[MimiKLM]

Thanks you both for replying.

I hope very well thank you.

Replying to TonP: I spoted 'Cache VIs' option in the Mass Compiler (MC) window and I though that MC keeps a number of VIs in memory (caching) what stops the correct compiling.

Replying to Hillman: The parent problem was (and still is) that during buildig deployment in TestStand (TS) the TS Deployment Utility (TSDU) reports a lot of missing, broken and duplicated VIs. So, I mass compiled my application directory, however it didn't solve the problem.

To both of you: Why you don't recommend of using MC? I though it is good to have recompiled VIs. What dangerous can I come accros using MC.

Links to parent problems: here and here

[Hillman]

Hi MimiKLM,

Thanks for your posts.

To confirm, you actual issue is now resolved then - you have managed to get TestStand to build? 

The reason mass compiling can be a cause of concern is that you are updating ALL VIs. As you can see, there are specific VIs which install for different types of applications, including TestStand API (of different versions) and for real time/fpga applications too. A mass compile fix for one issue could break another application. If you have multiple versions of LabVIEW, and one was a version of LabVIEW (for example) that isn't supported byTestStand, mass compiling could cause errors and issues.

As it has been highlighted to you in the parent issue - TestStand installed VIs in LV8, you are using LV8.2 and hence Mass compiling the TestSTand VIs is correct for your situation. 

Please let me know if you are still getting this error, 

[Ray.R]

If you have duplicated VI's, then a Mass Compile will be your worst nightmare.  Duplicated VI's meaning they share the same name but are located in different folders.  Mass Compile may actually "swap" which folder to get the same-name VI from. 

The nightmare will be to undo what Mass Compile did.

I believe that proper coding practice should allow you to use Mass Compile, and it does.  Good practice means that you never share the same name of a file.  And that applies to any programming language. 

R

[Rob_L2]

Hello All,

I am having the same problem. I am new to LabView and I am trying to Mass Compile an older version of LabView in LabView2012 and I get a bunch of the following type of warnings:

"Could not load C:\<project source path>\interface.lib\BuildHelpPath.vi because C:\Program Files\National Instruments\LabView 2012\vi.lib\utility\error.lib\BuildHelpPath.vi in memory"

I understand that these are warnings, but there are so many of them that they are disconcerting to the point I am not sure if everthing will work correctly. I thought that this would be a simple path fix in the .lib, but the window does not have an add or modify so I am not sure how to fix these.

Thanks in advance

Rob

[crossrulz]

Duplicate post over in the Version Conversion board.