LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.NET Issues with LabVIEW 8.5

My group is having some issues with some .NET functionality which we are using with LabVIEW 8.5

A small number of VI's get errors like the following whenever they are loaded:

    - The .NET assembly expected to be at "C:\dotNET_XML\dotNET_XML_LoadXMLSchemas.vi\<GAC>\System" was loaded from "<GAC>\System".

In this instance it is having problems with functionality from System.dll, other VI's are having similar problems with System.XML.dll. These VI's have been ported from LabVIEW 8.2 to LabVIEW 8.5, and we have tried all the obvious (to us at least) methods of fixing it (replacing all constructors, invoke nodes etc, rewriting from scratch in 8.5.)

What we can't seem to do is encourage all VI's to look for system.dll instead of trying to find it in their local directory, we've even changed our search paths so that the .NET framework is searched before anything else. We've created lvlib's for all VI's using .NET, and while this helps with minimising errors on loadup, it still isn't 100%.

Note that this doesn't affect the running of these VI's, it is however causing problems when trying to build exe's. 

Has anyone seen something similar and got a quick fix? If not, happy to supply some examples if it helps me get my executables delivered.

Cheers,

Liam
0 Kudos
Message 1 of 33
(7,594 Views)
When creating an executable get one of two errors. If it can't find the GAC then I get the following:

Error copying files.
Source: C:\dotNET Functions\dotNET_file version.vi\<GAC>\System
Destination: C:\builds\MES Test\Test 2\data\System

If I have the lvlib's in the project and if I'm lucky (it is a little random) to be able to open all of the .NET VI's without the <GAC>\System error, then I get the following error when building:

--

The VI is broken. Open the VI in LabVIEW and fix the errors.

Error 1003 occurred at AB_Application.lvclass:Open_Top_Level_VIs.vi -> AB_Build.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located.  Open the VI in LabVIEW using File>>Open and verify that it is runnable.

--

However, in this instance the top level VI is NOT broken, but when I open it I get the linking warnings such as:

    - The .NET assembly expected to be at "C:\XML Functions\dotNET_XML\dotNET_XML_OpenDoc.vi\<GAC>\System.Xml" was loaded from "<GAC>\System.Xml".
C:\dotNET_XML\dotNET_XML_ValidationReaderCallback.vi
    - The .NET assembly expected to be at "<GAC>\System.Xml" was loaded from "<GAC>\System.Xml".

Thanks,

Liam

Message 2 of 33
(7,559 Views)
Hi Liam,
 
Thanks for contacting National Instruments.  I have been looking into your question a little bit.  As you said, I am not surprised that you are able to run the VI since the computer was able to find the files that it was looking for, just not in the place it is expecting to find it.  I have seen someone have some similar issues before and I have attached a link below that gives some suggestions on how to fix the warning message problem.  Please take a look at this forum and try out the suggestions that are in it to see if you are able to get past the problem.  Also, another thing you could try would be to make some "dummy" directories to see if you can put the files you are loading in the "expected" directory.  I hope some of this helps and please feel free to reply back if you have some more questions about the same issue.  Thanks!
 
Regards

Noah R
Applications Engineering
National Instruments
0 Kudos
Message 3 of 33
(7,511 Views)
Thanks for you reply Noah.

We have looked at the directory structure and determined that this is not the direct problem.

We have been able to open all our .NET files in LabVIEW 8.2 without any problems, save them, then open again in LabVIEW 8.5. It is only in LabVIEW 8.5 that issues arise where it is trying to find the .NET Framework file 'system.dll'. This DLL is only stored in "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727", we do not (and do not want to) create copies of this in the local directories as this will definitely cause problems.

As mentioned before, it seems some of the VI's keep a reference to <GAC>\System.dll internally, which conflicts with the actual location in the Windows directory. This is why we get the following (when opening a VI called dotNET_XML_LoadXMLSchemas.vi):

- The .NET assembly expected to be at "C:\dotNET_XML\dotNET_XML_LoadXMLSchemas.vi\<GAC>\System" was loaded from "<GAC>\System".

Cheers,

Liam

 
0 Kudos
Message 4 of 33
(7,500 Views)

Hi Liam,

Thanks for the response.  A few things have changed in 8.5 with calling .NET Assemblies when compared to 8.2.  Possibly the best solution would be to create a new VI that is calling the same DLL's and see if you see the same problem.  Often, VI's store some information and references in them.  Also, another thing to be careful of is when you are referencing a DLL in LabVIEW, make sure that the DLL that you are referencing is the one that is located in the C:\WINDOWS\Assembly directory.  It looks like you may be referencing the System.dll in a different directory.  Please try these suggestions out and let me know if you are continuing to see the same error.  Thanks and good luck with your application!

Regards

Noah R
Applications Engineering
National Instruments
0 Kudos
Message 5 of 33
(7,464 Views)
It appears as though the files are looking at another copy of system.dll on the disk, but I can assure you that there is no other copy. We have tried all mechanisms to force these VI's to be using it at this location, without any luck.

The only way which we can resolve this issue, is by recreating all of our .NET VI's from scratch - this must be done with none of the corrupt VI's open. (ie by taking screenshots). This is extremely time consuming, however is the only option we have left.

I trust that NI will look into this and ensure that these type of issues will not cause us similar headaches when (and if) we upgrade to the next version of LabVIEW.
0 Kudos
Message 6 of 33
(7,419 Views)
Yes, you are correct in that the way to fix the problem you are receiving is by recreating the .NET VI's.  This is because of an improvement that was made in LabVIEW 8.5.  Like I mentioned earlier, the reason you are having some problems is because some of the VI's do hold some references to old files and recreating them fixes this issue.  I'm glad you are able to get it working and good luck with your application!
Regards

Noah R
Applications Engineering
National Instruments
0 Kudos
Message 7 of 33
(7,395 Views)

I have run into the exact same problem.

Re-writting all our .NET VIs is not a reasonable solution.  I expect NI to either post a fix to this immediatly or send me a engineer to sit and re-write all my .NET VIs for me.  It is totally unacceptable to say this is an enhancement and force customers to waste time on something that should just work in the first place.

-John

Smiley Mad

-John
------------------------
Certified LabVIEW Architect
0 Kudos
Message 8 of 33
(7,304 Views)
Hi John,
 
This was reported to R&D (# 4E485CF2) for further investigation. [A possible workaround is reverting to LabVIEW 8.2.1 or earlier.] Thanks for the feedback!


Message Edited by Noah R on 11-29-2007 05:54 PM
Regards

Noah R
Applications Engineering
National Instruments
0 Kudos
Message 9 of 33
(7,248 Views)
Same problem here. I get the following error every time I open the vi:

- The .NET assembly expected to be at "Create Document.vi\<GAC>\System.Xml" was loaded from "<GAC>\System.Xml".

This may be obvious but the problem only seems to affect vi's calling .net assemblies that are in the gac.
My vi's that call custom assemblies, not in the gac, load just fine.

0 Kudos
Message 10 of 33
(7,223 Views)