.NET Issues with LabVIEW 8.5

[THailey3]

Just to clear some things up, this is an obvious bug in 8.5.  We in no way intended for users to recreate their VIs that called .NET assemblies in LV 8.5.  As Noah previously mentioned, this was reported to R&D (# 4E485CF2) and is being given high priority.  I will make sure to get this added to the LabVIEW 8.5 Known Issues document.

Contrary to Noah's previous recommendation of downgrading to to 8.2.1, I'd recommend to sit tight for a couple of months (if you can wait).  If you can't, I'd recommend contacting support to explore other options.  When contacting support, mention that your facing bug 4E485CF2.

[jlokanis]

Yes, it does only seem to apply to VIs that call GAC assemblies.  So, only things that are part of the Microsoft released .NET framework.  Which for me is just about everything.

A few more interesting tips:

To work around this issue, you need to rewrite your VIs in 8.5.  You cannot have any of the offending VIs open or have ever opened then in this session of LV8.5.  Here is my process:

1. Open a bad VI.

2. Take a screen shot of the block diagram.

3. Paste the screenshot into any image editor/viewer so you can refer back to it.

4. Delete any .net nodes in the block diagram that call the GAC assemblies.  Also, delete any refnum controls or indictors that you might pass in or out of the VI that refer to GAC assembly references.

5. Save the VI (it will be broken).

6. Close the VI.

7. Reopen the VI and verify you do not get the GAC warning message.

8. Close LabVIEW 8.5.  (You must do this so LabVIEW 'forgets' about the GAC assemblies location.  Otherwise, if you try to fix the VI now, it will just be broken again.)

9. Open LabVIEW 8.5.

10. Open the edited VI.

11. Recreate the VI components you deleted, using the snapshot as a guide.

12. Be sure to reconnect any front panel terminals to their proper points on the connector pane.

13. Save the VI.

14. Close the VI.

15. Open the VI and verify you do not get the GAC warning.

16. Test the VI (if you can test it in place).

Repeat this for every VI you have that has .NET nodes and/or front panel terminals that are associated with any assemblies in the GAC.

Special note: When you load a VI that calls other VIs that you already fixed, they will be re-broken in memory.  After you delete the offending nodes/terminals from the parent VI, save it BUT DO NOT SAVE the sub-vis or you will re-break them.  After you restart LabVIEW, to fix the parent, the sub-vi should load ok without the warnings.  If you ever see the GAC warning after restarting LabVIEW to fix the VI you edited, stop what you are doing and retrace your steps.  You could easily re-break everything you are doing if you are not careful.

I am 2 days into my edits and about half way done.  So far, so good.  Fingers crossed.  I have even tested some of the fixed VIs and they will now build, so I am confident in the workaround.

Good luck,

-John

[SamboNI]

Hey John,

Thank you for posting your very detailed steps to address this issue. I can confirm that on my machine, following these steps resolved both the warning dialog and the error 1003 for building and previewing the build of an Application (exe) in a VI that called a .net assembly in the GAC.

Thanks again!

[jlokanis]

Glad I could be of help.  I am told this bug will be fixed in 8.5.1.  I just could not wait until then and I needed some of the 8.5 features for my project.

-John

[HJPhilippi]

Hi John,

your elaborated workaround description is greatly appreciated, alas it doesn't really help us: We have loads of VIs with uncounted .NET nodes, I/O types and wires, and recreating them all would take weeks... Do you know of a release date for a forthcoming 8.5.1 that will address the issue?

BTW: It's not only .NET Framework stuff from MS themselves causing problems here. We have created a set of own .NET assemblies written in C# and intentionally placed them in the Global Assembly Cache to avoid LabVIEW referencing specific DLL paths on disk, with all its search and (not) found bustle... And now this.

Greetings,
Hans

[Travis_M.]

Hello, NI has not released any information on possible future LabVIEW versions and unfortunately we can't guarentee any particular issue will be fixed in any specific LabVIEW version.  If you have further questions please contact NI support directly via phone or email.

thanks,

[mikemattball]

Is there any word on an 8.5.1 release, or a fix to this problem?  This is the one thing that will be work for me to migrate to 8.5 (that I know about right now).  I don't use a ton of .NET, but enough to make this annoying.  I'm hoping to save a couple days of rewrites if a fix is out or almost out.

It looks to me from some Google snooping that 8.5.1 almost came out in January, but it apparently didn't make it.  Any news?

Thanks,

Mike

[Travis_M.]

Google? LabVIEW 8.5.1?  Never heard of 'em

If you are interested in following the latest updates, we post all new software releases to the NI Drivers and Updates page here.  In year's past, we have updated this page within a day or so of the software release.

[mikemattball]

Thanks, Travis.  I checked there this morning, but of course there's nothing there.

You've got the company line down perfect.  I'd recommend you move into management. 🙂

[_Bryan]

The link to 8.5.1 just showed up for me today

It looks like you have to go to the services resource center, under support, then find software upgrades by title.  It does not show up under the regular drivers and updates.