Runtime .exe saying 7.1.1 when it was built on 7.1

[davidpcl]

I have built an executable using LabVIEW 7.1 and have then installed this on another machine that has the 7.1 runtime engine on it, however when you try and run the .exe it says that it needs runtime engine 7.1.1!

I have never had Labview 7.1.1 development or runtime on my system - so why on earth does it think it needs it? On top of this it also now prevents any other labVIEW executables running on that PC.

Any ideas appreciated,

[JeffBoettcher]

Hello David,

Have you tried running this built EXE on any other machines?  If so, do you see the problem on the other machines, or just on the one machine?  What is the exact error message you get when running it on that machine?  Do you have any drivers installed on the problematic machine?  If so, which one(s) and what are the versions?  Some drivers might install the 7.1.1 runtime, however, 7.1 applications should be fully compatible with the 7.1.1 runtime, so I too am a bit confused as to what would cause the problem you're seeing.

If you're looking for a quick fix, there's a reasonable chance that going into Add / Remove programs on the problematic machine and asking it to repair the 7.1.x (whichever is listed) runtime would fix the problem, but it's hard to know for sure, the information requested above would help identify this.

Good luck!

[Ian_Ren]

I am facing the same problem. I built the application on a machine with

LabVIEW 7.1 (Developers Suite August 2005)

Max 4.0.3 (Developer Suite May 2006)

Also installed from May 2006 CDs are

LabVIEW 8.0, LabVIEW Run-Time engine 6.1, LabVIEW Run Time engine 7.0, LabVIEW Run Time engine 7.1, LabVIEW Run Time engine 8.0, NI-DAQmx 8.1.0f1, Traditional NI-DAQ 7.4.1f4.

The exectutable runs fine on the machine that built it. However,  if I install and run it on to a different machine with device drivers (MAX from Developer Suite May 2006) installed but without LabVIEW, I receive an error telling me "Executable version (7.1.1) doesn't match resource file (7.1). Check you configuration".  If remove the MAX first, then install the executable, I can run the program without the same error. However, I need MAX (device driver) for DAQ.

I did fine a solution. If I install the executable first, and then install MAX, everything works fine., but I do not want to remove/reinstall MAX every time I install an executable.

Where does version 7.1.1 come from? What is the solution?

Thanks.

Ian

[Ian_Ren]

Just find something from KB

http://digital.ni.com/public.nsf/websearch/6BB601AE18D54C2186256F6C007FD775?OpenDocument 

http://digital.ni.com/public.nsf/websearch/680E61A4D02158A186256F7A0073C228?OpenDocument 

but how to upgrade to LabVIEW 7.1.1? I have development suite, but only have LabVIEW 7.1 (August 2006) and LabVIEW 8.0 (November 2005).

[kehander]

I ran into something like this problem once when I tried to run an application compiled with LabVIEW 7.1 on a computer where the 7.1.1 runtime was installed.  The most elegant way around it was to copy the 7.1 version of lvrt.dll to C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\7.1 , renaming the 7.1.1 version that was already there.  (Yes, the 7.1.1 and 7.1 Run-Time engines get installed in the same directory!)

If you need the 7.1.1 Run-Time engine, isn't http://digital.ni.com/softlib.nsf/websearch/369618104e25b08e86256f54006a4e2f  what you need?

Message Edited by kehander on 07-28-2006 05:23 PM

[Ian_Ren]

Now I have a new issue. I installed the executable and MAX 4.0.3 (including NI-DAQmx 8.1.0f1 and Traditional NI-DAQ 7.4.1f4) to another computer, but the program can not be loaded properly (error code 21, an external subroutine required for execution could not be found). The vis that have problem are all related to NI-DAQ.

The executable is built using LabVIEW 7.1 (Developer Suite August 2005 version) and runs fine on another machine which at one time has LabVIEW 7.1 installed but later the LabVIEW was removed.

What is the solution? I do need to keep both LabVIEW 7,1 and LabVIEW 8.0 on my master computer.

Thanks

Ian

[kehander]

If all else fails, I often find Filemon from http://www.sysinternals.com to be useful in cases like this. I doubt it will point out individual missing VIs, but it is useful if there's some missing or incorrect DLL somewhere.

[Sarah_Coleman_NIUK]

Hi Ian,

Are you using the traditional DAQ VIs in your application? That error you listed means your VI is trying to make calls to a DLL that isn't present on that machine. I would guess that the install didn't run properly. Or all the necessary support for your application didn't install. When you install the driver software you should make sure and restart your PC before trying to run the application.

You're installing all the drivers from the device driver cd aren't you? You could be deselecting something in the installer setup that is necessary for the code to run...

As MAX and NI-DAQ both get installed with NI-DAQmx 8.1 I would suggest downloading the DAQmx driver from the web, burning it onto a CD and using that to build all your deployment machines:
http://digital.ni.com/softlib.nsf/websearch/d31d46fffb745eca862571490053eab8 

Did you ever get the problem with LV 7.1.1 solved? If you need the maintenance release it's on this link:
http://digital.ni.com/softlib.nsf/websearch/6C5F342A4AF4EF8986256F5400693C3B?Opendocument 

Let me know how you get on with the install of DAQmx 8.1,

Message Edited by SarahB on 08-03-2006 08:55 AM

[Sarah_Coleman_NIUK]

Hi Ian,

For future reference, if you have a new support query you're better off starting a new thread in the forums then reposting on an old thread.

When you post on an old thread, only the people that originally posted on it will be know about it. If you start a new thread, users and NI support engineers who monitor the forums will see it and can try answer it.