cannot open a vi with seperated compiled code

[richjoh]

Anyone know how to resolve this issue.

Occurs on the target PC, due to reverting to LV2010 from LV2010SP1 project on development PC. I build an exe and installer and run the installer on target PC. Installing the LV2010 runtime on target didn't work either.

[altenbach]

What happens if you uncheck the option "seperate compiled code" (on the general properties page) for that file (or all files)?

(You can also do this for the entire project on the "project properties" page)

[richjoh]

Uncheck and did a mass compile no change in errors. I believe by creating a lvclass (nothing more than a LV library) using SP1, then deleting the class it caused this issue, http://forums.ni.com/t5/LabVIEW/Mass-compile-crashes-LabVIEW-2010/m-p/1530120#M568966. I decided to go back to  LV2010 and now can't get the target PC to work.

[Cody C]

Good Afternoon,

Have you considered creating a new project, adding all of your VI's to the new project, and then recreating the exe in the manner like Paul suggested at the thread that you linked?  I hope you have a great rest of the day!

-Cody C

[wired]

Unchecking the 'Separate compiled code' option at the project level does not uncheck the option in any of the VIs that are already in the project.  I tried unchecking the project level box and doing a mass compile, and the individual VIs still had the option checked.

This seems to be a real stumbling block for developers who are using source control.  We would like to separate compiled code from source for source control reasons, but if we want to try building the executable app, code with a dynamic VI call will fail with error 1574.  Am I missing something here? How do we test applications without messing up source control and/or going in an changing the option for all of our dynamic VIs?

[richjoh]

run the executable in debug mode, you will find a dependency VI that has compiled code seperated from source. You may find the VI too by going through your dependency VIs, looking at VI properties in your project but since its not the build no errors. In my case, I discovered such a VI in my vi.lib directory of LV2010. How that got that way, I have no clue, since I diverged in LV2010 SP1 and back to LV2010.

[wired]

I know which VIs are causing the problem - it's any VI that is dynamically run. The real question/problem here is how one can effectively utilize source code control options while also being able to build applications.  I believe creating source distribution is an option, but IMO one should not have to do anything different during the build process than what would be done if the compiled code were included with the source.  Perhaps any VI that is 'Always included' should be treated differently by the application builder. If all of your files are spec'ed to be part of the EXE, the builder should do what it needs to do to ensure that this error does not occur.

My .02... NI dropped the ball on this one.

[Ad_Dekkers]

I have the same problem.

I created an application that (in lv7.1) was possible to run ANY labview vi.

Now with some vi's in the vi.lib with separated compiled code most of the vi's arn't runable anymore !!

NI please solve this issue as soon as possible !!

[Yamaeda]

If you're building an exe with dynamic vi calls, it _must_ be included in "always include". The separate code/front panel issue is when running vi's directly in run time engine.

(Unless i've misunderstood something)

/Y 

[Ad_Dekkers]

No it was possible to run any vi, without including it in your .exe.

We have an application that's controling all kind of instruments.

If i must include all dynamicvi's in my .exe it has the folowing drawbacks:

- I have to make a new build for every new instrument.

- The application will get larger and larger

- Finaly i will run out of memory while building the .exe.

- I changed to win7 64 bit, to cope with this and now i run into the "lazy icons" bug of lv 2011 (with no good solution nearby)

So please make it possible to dynamicly run any vi from an existing .exe !

Possible soloutions:

- Make the vi separated compiled code available for the run-time engine

- Give the option to do a source code distribution with the separated compiled code disabled for ALL vi's (also the vi lib and other ni vi's)

- Give the posibility to update the complete vi lib with the separated compiled code disabled.

Anyway: GIVE US A WORKABLE SOLUTION !