Why do I have to recompile, when .dll's get updated. Labview compiler question!

[HomelessD]

Please forgive my ignorance, since I was not formerly trained as a programmer.  I am making calls to some 3rd party .dll's that get periodically updated on my computer.  I have found that everytime I use 3rd party installer to update the .dll's/.net framework, one of the property nodes in my code causes an error.  The specific property node calls one of the .dll classes and returns a .net refnum.  Old versions of .dlls work fine, new versions cause error.  So I assumed that it was an inconsistent Class, Method,.. naming, location... I was wrong.  If I press the <Control + Run> button to force a compile, everthing works again on my code.  Works with the newer version of .dlls that were just updated.  What is happening under the hood.  How come the compiler can open other class references, but not the .net reference without recompiling??  Let me go over again incase of ambiguity...

1) Working labview Code makes calls to 3rd party .dlls

2) Upgrade .dll's using included installer

3) Rerun labview code, class calls that return .net references cause error, previously worked well

4) Force a small compile "Control + Run"

5) labview code works again, .net refnum is valid

And the million dollar question.  Once I go to executables, how do I keep up with .dll updates.  Do i have to run 3rd party installer from labview installer, or do I just include their .dlls in my folder.  That is what I keep reading I have to do, but in that case, i have to create a new installer for every revision of .dll's... surely that is not the way!!!

You can't hurt my feelings, I'm a wramblin wreck..

Fire away, and thanks in advance

d

[Eriquito]

Hi HomelessD,

What error message are you getting, exactly?

PS:  Go Jackets!

[HomelessD]

Eric,

Thanks for responding.  I almost gave up looking for people to reply.  For some reason I didn't see an email.  I will take a screen shot later, but for now, it says roughly "property not found".  I will repost tonight.

It was very unspecific.  I started by thinking that the new .dll's had something wrong with them(changed function name, inputs/outputs changed...) When I got them on the horn, they said that it was normal for me to have to rebuild my project when I update their .dll's, and specifically said the problem was due to the .dll's have a revision number associated with it.  And somehow this will keep me from accessing the new ones, when I update .dll's without recompiling labview caller.

I do not know if this helps, but the particular .dll that gives me problems creates a .NET reference that I pass into other .dll's.  I created an example to illustrate the problem to the "Other Guys", and I could send it to you also, but I think you might need hardware to make them work.  I could however setup a "GoToMeeting" and illustrate the problem I am having.  Can you support in that manner?  I demo'd it before, and it took about 10 mins total.  Contact me via email, if you can meet during the week.  Thanks again...

PS.   Not a stellar BB season, but I see it like this, ACC tourmament is just a "little longer run" for the national title.  🙂

Thanks for your help,

d

[Eriquito]

Hi HomelessD,

Unfortunately, I can't do any kind of remote conferencing, and I'm not sure it would be of much help anyway.  I do have somesuggestion, however.  If you are using the Call Library Function node, you may try using a CIN instead.  Also, if you need multiple .NET references, try using a .NET Constructor node.

[Britoa]

I have been having the same problem with an API we are doing here (I am just using the API).  Anytime the API gets rebuilt, the exe needs to be rebuilt, or it has problems setting up the first callback VI (it may do the same with the other two, but I am pretty sure the error cluster would prevent it from trying).  I always blamed it on a different version number that may have been hardcoded in the exe.  For us, the problem is a test suite to test the hardware the API is written for, and is only on one computer right now, so the problem is not such a big deal. 

This happens in both 8.2 and 8.5 (don't know about 8.2.1)

[HomelessD]

Britoa,

You explained it much better than me.  The .dll I am using is not just a single function but an API.  What is weird in my case though,  without chaning any code after updating API, is it will actually make the first two call backs, but on the third one( wich returns a .NET reference ), it crashes.  And your right, it would be hard to verify if anything works beyond that, because the error gets passed through the remaining code.  If I change anything on the block diagram, it recompiles to the newer version of API and starts to work. I am not sure that this is a .net problem as much as a "compiler to revision number/OS .dll to Labview" problem.  Right now its not a super big problem, but when I start making exectuables and distributing this software to customer, it could be a big problem.  

Does anyone have a better solution, than to manage the releases of the API?  

This brings up a second issue, you can sequence a third party installer, from the labview installer right?  I guess I need to start doin research on this, if there isnt a better solution. 

Eric,

I am using constructors, which work fine under the old API, but when I updated the .dll's, it stops working until I recompile.    I do not think im using a call library function node, I am using constructors, and property nodes, and methods nodes.  Keeping track of references that I create.  I am sorry if I answered this poorly.  Like I said before, not formerly trained....

 Thanks for everyones response,

Derrick

[RobBoyer]

Hello,

.NET was specifically designed to avoid versioning issues like this.  In theory, there is no reason why a new version (even with a different version number) should require you to re-build your application.  The only thing that should cause you to need to re-build your app is if any of the existing interface has changed.  (For example, if one of the properties or methods that you use now has a different parameters list, or if any of the parameters are of a different data type, then this behavior should be expected.)  Otherwise, this would point to a weakness in LabVIEW.

On the other hand, I did a simple test to try and reproduce the problem you are seeing and I cannot.  (I am using LabVIEW 7.0, and even in that version this seems to be working correctly.)  Nevertheless, it is certainly possible that the complexity of the DLLs you are using are exposing a true bug in LabVIEW.

One thing that might be of value (if you, or someone you know has some experience in a .NET language) would be to try to reproduce the problem by mimicking the behavior in a .NET program.  If you are forced to re-build the application, even using .NET, then you can rule out any LabVIEW issues.  And then you can ask your 3rd party vendor why they insist on changing the existing interface with every release. 🙂

Rob

[RobBoyer]

Oh yea - one more suggestion:

If the DLL(s) comprising the 3rd party API you are using gets installed in the global assembly cache or GAC (which is very likely), this will complicate things from LabVIEW's perspective - I didn't test that in my experiment.  And I do know that LabVIEW has historically had some problems integrating with the GAC (for example, version 7.1 had a bug which would cause it to crash whenever you attempted to create a constructor node).  If that is the problem, you could try manually copying the DLLs that are necessary into the same directory as your executable and linking your constructor nodes to them.  That would help you rule out GAC issues.

Rob

[HomelessD]

Rob,

Thanks for your input.  You have verified my first assumption.  I have a direct connection to the 3rd party vendor, and I mentioned to them that it was something simple like a function name, i/o varialble name or something a simple as returning a double instead of an integer changed in their API.  They swore nothing changed like that was possible. 

Hopefully, someone will own up to the error, so I can get a proper fix instead of a weak work around.

Thanks again,

Derrick

[HomelessD]

Rob,

Yes, I have seen that posted before, copying the .dll's into the same folder as your Labview source code.  I will try this, but this is another workaround.  I was hoping that my customer could just load new 3rd party updates and not have any problems with my executibles. 

The 3rd party software does seem to save their .dll in the same location evertime.  Maybe I should have labview installer put executables in the same folder as their .dll's?  Is that what your saying?

Thanks in advance,

Derrick