can not built a working application (with LVOOP and .NET)

[shb]

Hello everybody,

I want to built an executable from my LabVIEW project, but I do not manage to built a running one. I work with LabVIEW 8.2.1 and use LVOOP and .NET on a computer running Windows XP. I have read the following tread concerning problems with LVOOP. http://forums.ni.com/ni/board/message?board.id=170&message.id=261604&query.id=109973#M261604

In my built specifacation, there is checked "Do not disconnect type definitions or remove unreferenced members" and "Enable Debugging". With this options set, I can built the application. But it is not runnable, even on the development computer. It tells  that the Development Version is needed to solve this problem. In the development environment, the program runs without problems. When I try to debug the execuatble, LabVIEW crashes while downloading the VIs.

Does anybody have a succession how to solve the problem? Please do not tell me that in LabVIEW 8.5 the problem may be solved. I wold like to use this Version, especially because of the reentrant VIs (Shared clones). But I do not have it.

Thank you for every answer you write.

Greetings,

shb

[Britoa]

this may or may not be your problem, but do not have any class based VIs as dynamic VIs in the build properties.  Something about the classes automatically knows what is dynamic and what is not.

[shb]

Britoa, tanks for your suggestion. There is no VI listed as dynamic VI in the built properties. The problem must be something else, but I still do not know it.

I found a way to run the application. I built an executable which loads the main VI dynamically and starts it. On the development computer, I put a link to vi.lib and one to user.lib in the directory where the main VI is. Before starting, the VIs in this location are searched for several seconds and all are found. The program executes correctly thereafter.

I copied the executable and all the files from the project (VIs, ...) to the destination computer. Instead of the links to user.lib and vi.lib, there are directories with this name. They include the used VIs from the original locations (preserving hierarchy, copying done by a VI). Loading the VIs is quite quick and the program runs now!

Of course  there is an other problem now. The call of the .NET constructor returns error number 1055 (invalid object) on the destination computer. The used dll was installed by the same setup. It locates in the same absolute path on bought computers. (The relative path it is different.)  Copying the dll in the directory containing the main VI and the executable or in a subdirectory does not help. The version 2.0 of .NET is installed on bought computers. The constructor is in a non reentrant VI. What do I have to consider else? I have no idea what I could try now. Does anybody have a suggestion?

Thank you verry much for every answer.

Greetings,

shb

[shb]

What does error number 1055 mean?

That the dll containing the class could not been found? I do not think so any more.
I made some tests after reading a thread about .NET and the LabVIEW help (heading "Maintaining .NET Assemblies"). The same error always occured. The dll was in the directory named data, in the same directory as the application and in the same as the VI calling the constructor. I copied the dll in a subdirectory of the project, included it in the project and recompiled the calling VI thereafter. I have rebuilt the executable. The dll should have been found at least once. I think this was a false trace.

So what does the error mean?

Best regards,

shb

[billings11]

It almost sounds like you need some sort of additional .net framework for labview to go with the run-time engine on the target PC.  It sounds like you are just getting some sort of generic invalid object error, as if the runtime engine can't even figure out what to make of the code.  I've never deployed .net through labview before, but it seems like you get the same type of invalid object error if you try to do a VISA communication in an exe but forgot to deploy NI-visa on the target PC.  Maybe it is something like that?

Message Edited by billings11 on 01-24-2008 12:44 PM

[Johann.Wagner]

Hi,

i found another question to error 1055 (invalid value):

http://forums.ni.com/ni/board/message?board.id=170&message.id=228555&requireLogin=False

Can you attache the *.exe with the *.vi here in the forum (or a simply version whose has the error)then i try it with lv 8.5 and ask our developer. Can you test it with LV 8.5 - maybe there is no error.

Best Regards 

[Johann.Wagner]

you can test the *.exe building in LV 8.5 30 days test (evaluation version) yourself - downloading here:

German version

https://lumen.ni.com/nicif/d/lveval/content.xhtml 

USA version

https://lumen.ni.com/nicif/us/lveval/content.xhtml 

[shb · Accepted solution]

The executable works!  

Thanks a lot to everybody who spent time by reading the thread and thinking about and of course to those who helped by giving hints. And excuse me for not writing earlier. I did not know what to write because I could not interpret the results of my tests. About an hour ago, I had good luck and found the problem. Here it is:

I wrote the VIs handling the .NET code and installed a newer version of the product thereafter. There was a message about the version change the next time I opened the VIs containing the .NET code. I saved them (as LabVIEW wanted to do) and tought that they are updated. I wondered why the message appeared again sometimes when one of the VIs was opened. In the context help of the wire of a .NET class, there was written the old version number. I tried to change this by reselecting the constructor. The number did not change. It might be only a display problem. My program was working, so why should I worry? But it seems that an executable cares about the correct version. (At least one who is not on a development computer.)
I waisted a lot of time by searching solutions and writing debug code. One attempt was to update the VIs to show the correct version number. I found two solutions for this. You can delete the constructor and place a new one. Or you can choose that the constructor is from another class, reopen the dialog and select the original constructor. The same you do for all the controls and indicators representing a .NET class. After doing this I copied the new VIs to the target computer. My hope was little that the executable would run correctly now. To my great surprise, there was a new error message. After correcting a mistake in the path to the configuration file, there was no error.

I wonder if Lila K in the tread Johann.Wagner mentioned had the same problem. I miss the solution of the problem.

The executable still calles the main VI dynamically. The executable including all the VIs does not start. But now I can run the application on a non development computer. This is the main thing. And I have learnt a lot about building an application, search paths, .NET, debugging, creating and using probes, writing in english and in french... I hope I can use this knowledge another time.

Have a nice weekend

Greetings,
a relieved shb