.NET freezing

[smercurio_fc]

---

Been bitten by LabVIEW wrote:

As far as I'm concerned, since LV is not using the .NET 3.5 framework directly, it really shouldn't matter, because it is a library, not a language.

And you can say what you will.

---

And you can say what you will as well. It's still not going to change the fact that LabVIEW is accessing the .NET framework because it has to.

Cheers. 

EDIT: Also, the fact that your code runs 1700+ times with no issues doesn't change the fact that .NET 3.5 is not officially supported in LabVIEW. 

Message Edited by smercurio_fc on 06-17-2009 11:02 AM

[Been bitten by LabVIEW]

LabVIEW is accessing the .NET framework that it knows about, nothing more.  The fact that my stuff is accessing a framework that LabVIEW doesn't know about is irrelevant.

It is like saying that Person A is delegating work to Persons B and C.  If A want's stuff done that it knows B can do, so it goes to B.  If A want's stuff done that it knows C can do, it goes to C.  Does it matter that C goes to D to get the work done and not B?  No.  Person A couldn't care less.

Cheers.

Message Edited by Been bitten by LabVIEW on 06-17-2009 11:20 AM

[Been bitten by LabVIEW]

---

smercurio_fc wrote:
You indicate that you're using LabVIEW 7 and .NET 3.5. .NET 3.5 is not supported in LabVIEW 7. LabVIEW 7 only supports .NET 1.1. LabVIEW 7.1.1f2 barely supported .NET 2.0.

---

BTW, have you written any .NET assemblies for LV or for any other programming language that had marginal .NET framework support for a particular version?

Did you have any issues in linking your .NET assemblies to that other language?

[smercurio_fc]

I have no idea how to answer those questions since I don't even understand what they mean.

Why would I write a .NET assembly just for LabVIEW, and why would I write using a framework that's not supported by LabVIEW? That makes no sense to me. 

[Been bitten by LabVIEW]

Are you a software designer/developer or an electrical engineer?  Why would you not write a component "just" for LV?  Sometimes LV doesn't have what is needed to do the entire job but can do most of it nicely, so you interface it with something which can do the rest.

And if you notice, I did not say anything about using a framework that is not supported by LV, though it may be a bit marginal.

Cheers

[smercurio_fc]

You misunderstood my comment. I understand the concepts and technical things you are saying. I just don't understand the premise and/or purpose of your questions, and I no longer have any idea what you're talking about, so I have no reason to continue a one-sided conversation.

---

Been bitten by LabVIEW wrote:

Are you a software designer/developer or an electrical engineer? 

---

I'm both, thank you very much. 

[Been bitten by LabVIEW]

---

smercurio_fc wrote:

---

Been bitten by LabVIEW wrote:

Are you a software designer/developer or an electrical engineer? 

---

I'm both, thank you very much. 

---

Sorry, I wasn't trying to be rude, I was just trying to understand why you don't understand the premise and/or purpose of my questions, which is to create a .NET assembly to use inside of LV while avoiding potential pitfalls.

In any case, I also got some very useful info from the MSDN .NET forums.  It seems that I am right and was also a little wrong (still trying to get a clearer answer) in how LV (and all other applications) interface with an assembly.  The JIT compiler will compile the assembly to a form that is requested by the application (in this case LV would request it in a form of version 1.1).  Most things will work correctly except for specific things that were introduced in 2.0, such as added security and the like.  LV will then be able to 'talk' to the object(s) just fine.  If I were to use something that was introduced in 2.0 (not necessarly an assembly, but something that the 2.0 CLR introduced) then an exception will be thrown or it just won't work.

.NET 2.0 -3.5 SP1 all use the same CLR.  I was assuming that the CLR didn't change in versions even before that so that I could use a later version of .NET without issue, however I was incorrect about that.  But because the JIT will compile the assembly to 1.1, I'm good to go unless, as I said before, I use some feature of the 2.0 CLR which may be hiding in a more advanced MS assembly.  So as long as I stay away from the more advanced stuff, I should be fine.

Again, if you thought I was rude, I do appologise.  That wasn't my intent.

Cheers.

[smercurio_fc]

Yes, I thought your question was somewhat of a "do you even know what you're talking about" kind of question. Especially in light of the fact that you kep trying to convince me that LabVIEW wasn't using the .NET framework directly, or trying to tell me what the CLR is when I've programmed several .NET apps. Whatever. The bottom line is this: you initially asked why your code sometimes froze. You indicated you're using LabVIEW 7.1 and .NET 3.5. I've said several times that (a) LabVIEW 7.0 only supports .NET 1.1, and (b) .NET 3.5 isn't officially supported by any version of LabVIEW. It doesn't matter whether the CLR for 2.0 and 3.5 is the same, and it doesn't matter what the JIT compiler may or may not do. Unless NI can verify functionality of .NET 3.5 with a version of LabVIEW it's all speculation.

[Been bitten by LabVIEW]

True, it is not supported and it is speculation if it works or not because of that, but hey, it is not without reason for it.   I figure, if it has the basics down well enough, it is worth a try.

As for LV using the .NET framework directly, well I'm not going to bother trying to convince you of what I am talking about since you seem to be pretty set in your views.  I'll just agree to disagree. 

Anyway, I'm not worried about the freezing anymore.  Thanks for the help and the discussion to hash things out.

At some later point, I'll post a sample app as to how I did it, in case anyone is interested.

Cheers.

Message Edited by Been bitten by LabVIEW on 06-19-2009 08:45 AM

Message Edited by Been bitten by LabVIEW on 06-19-2009 08:46 AM