Old .NET reference doesnt go away from Labview

[Ratin]

I have a .NET assembly reference thru a .Net dll
(Soloist.Classes.dll, version 1.1.0.0) that I addded in Labview
and call the constructors/methods. Everything was ok until I did
a rebuild of my .NET dll(Soloist.Classes.dll, version 1.2.0.0).
I updated the vi by removing the reference to the old assembly
and added the new one (The name of the dll didnt change, the
version did). But somehow when I bring up my vi's,Labview complains
that I dont have reference to my old version (?). Why is it still
looking for the older dll? Here is the warnign message I get up
launching the vi:


WaitForTaskStatusBit.vi
Virtual Instrument
- LabVIEW does not have references to the following .NET assemblies used by this VI:
Soloist.Classes, Version=1.1.0.0, Culture=neutral, PublicKeyToken=478e72719c32735e
Please add references to those assemblies by selecting "Tools>>Advanced>>.NET Assembly References" before editing the VI.

I will appreciate any help on this.



Ratin

[AnalogKid2DigitalMan]

I had some intermittant shenanagins like this happen once a while back in v7.0. I found that if I did the following, things went well:
Make sure you delete the old dll from the folder and copy the new one in (the dll must reside in the same folder as your vi)
Open the vi and update the reference.
Also right click on your constructor node and select the proper constructor.
Save the vi, Exit LV, and then reopen vi.

Hope this helps

[Ratin]

Yes I just found this out that I have to re-select the
classes for the .net references, which is going to be painful
everytime the dll changes (I have created about 30/40
distributable vis that goes along with the .net dll).
So for every new version of the dll, I need to re-select the
references! I wish the Labview developers could come up with
an autometic referencing method that would simplify my task 🙂


Ratin

[AnalogKid2DigitalMan]

Ratin:

I sympathise with you. Upon realizing this while prototyping an app, I purposely made all .Net dll calls for read/write operations to one of our databases as part of my top level app. The refnum was intially created, kept alive, and then disposed of only when app was to be exited. Copious use of bundles/shift registers passed old and inserted updated data along so I could tap off of them to put/get data. That way I only had to modify my references/constructs in 1 vi.

I agree, it is quite cumbersome. Hopefully NI will get it better next try.

-Pete

[Ratin]

Pete, Thanks for your reply. Initially I was thinking it would be
nice to call the constructor, and then save the refnum to a
global variable (of type .net reference) but that didnt seem to
work. I couldnt create the property and method nodes from it, so
I gave up on that idea. I also thought about keeping the refnum
alive in a while loop and pass it around thru shift registers.
But that has a drawback, the vi executions seems to be slow. I
have done this for a previous project with a C dll where I had to
save a handle for calling functions off of the dll (slightly
different scenerio than the present one). A lot of people weren't
happy about the way system bogged down. So I saved the handle
in a global variable and that worked and people were happy. I wish
I couldve done this for saving .net refnums but alas! 🙂

Ratin

[Lycangeek]

This is a bit late but I've been coming up to speed on some of this myself. I'm a developer on the LabVIEW .NET team.

I've put together some information on my blog about how this actually works so I'll just point you over there. I made some assumptions about this problem, so if my explaination doesn't cover what you saw, please let me know.

http://detritus.blogs.com/lycangeek/2005/03/labview_7_and_a.html

I also did a quick backgrounder on the .NET concepts on the previous post. Stay tuned for the next blog about how it is going to work in the future...

Hope this helps

Brian

[AnalogKid2DigitalMan]

Thanks Brian, I will pop in from time to time. I foresee myself doing more .NET dll calling via LV in the near future.

-Pete

[Ratin]

Brian, Thanks for shedding some light on this. Before you start
your long cold journey in 3 degree Kelvin temperature (:-), I must
assure you that I did add the .Net references and working within the same
directory as the dlls (I did both). May be I shouldn't add the references
when I am working from the same dll ? It is sorta clear why it says the
.Net reference isn't found, the version that it has in the database doesn't
match with whats in the current directory. Should taking the .Net reference
totally out fix the problem (ofcourse working from the same directory as
the dll).


Ratin

[Lycangeek]

I'm a little confused by your reply ("May be I shouldn't add the references when I am working from the same dll ?"), so I'll reply to part of it and say how it "should" work. I should also clarify as to whether you are experiencing a broken run button or a runtime error??? If you still have the code that doesn't work, please email it to me if you can -- or an example. I really want to make sure you aren't experiencing a bug that I am unfamiliar with.

When it comes to the .NET Assembly Reference window, it only affects the edit mode of LabVIEW. When you add the reference, it allows LabVIEW to find the assembly when dropping constructor nodes, etc.

When you actually run the VI, the reference window doesn't come into play because we call Load() during the constructor execution. This means we turn over to Fusion the searching for the assembly. At that point, the assembly needs to be

1. In the GAC, where the version string in the VI will be used to find the exact version in the GAC (not counting version policy files)
2. In the same directory as the top level VI. In this case the version should be ignored.

There is also a handy tool in the .NET SDK from Microsoft called FUSLOGVW.exe. It can be configured to show exactly what Fusion is trying to do. If you want, I can walk you through that one...hmmm, sounds like another good blog entry 🙂

By the way - I am happy to report that this Constellation will be a lot hotter than -3K! I'll try to get that entry done this weekend.

Brian

[Ratin]

Hello Brian, I am still experiencing the problems. I explicitly added the references in the
GAC and looked at the listing. Attached is the jpeg image. I am getting the error message
during run time, not design time.

Hope you can help me, this is getting really frustrating!

Thanks,

Ratin