Hi, I'm running a .NET component that I have created, but occasionally, when I run it in a VI, the labview environment freezes. Since I'm debugging, it is after a compile, but it doesn't always do that. Strange thing is after a freeze, I kill LV and run the same VI again (no recompile of the .NET assembly, no changes to the VI), and lo-and-behold, it works, so it doesn't appear to be my code.
Has anyone else experience this issue or know what this could be caused by? I need this code to be solid, so this won't do.
It appears to be at the point of calling the constructor.
Thanks for your help,
Running LV7.0 on WinXP SP 2 and .NET 3.5, VS2008
But I am not actually using the Framework from LV, and since the CLR hasn't changed, does this really matter? I'm only using it for the interface capabilities, like that of a COM object. All of my calls pass only strings, ints and at worst an array of ints.
You are using the framework if you're calling .NET, and I don't understand what you mean by "the CLR hasn't changed". It does not matter what you're passing.
Now, it's possible that it's your .NET component that's causing the problems. However, as I indicated before, LabVIEW 7 does not support .NET 3.5. In fact, no version of LabVIEW officially supports .NET 3.5. If it's not proprietary you can upload your .NET component and someone else can test it for you under a newer version of LabVIEW, or you can try to download the trial version of LabVIEW 8.6 to see if that makes a difference.
The CLR is the Common Language Runtime. It the 'glue' that binds. This is the interface between LV and any .NET assembly. So I figure that if the interface is the same and I'm not directly calling a .NET 3.5 object from LV, I should be fine.
I'll see about dling the LV8.6 and see if that works.
BTW, is it possible to embedd a front panel in a subpanel if the front panel is a seperate LV application? And can I send events to it? If this is the case, I may try and mitigate by running that app and if it crashes, restart the app and try again. It looks like if it works once, it works forever after. Very strange...
I'm well aware of what the CLR is. And it's not "glue", as it doesn't bind anything. It provides conversion from byte code to machine code. But you already knew that right?
I just did not understand your statement "the CLR hasn't changed", and I understand "I'm not directly calling a .NET 3.5 object from LV, I should be fine" even less. Why are you saying you're not calling a .NET 3.5 object from LV? Aren't you using a .NET assembly and using a constructor?
As for your question about subpanels: You can place a subVI in a subpanel, but not a compiled LabVIEW application. I don't know how doing so will help you.
To enable the runtime to provide services to managed code, language compilers must emit metadata that describes the types, members, and references in your code.
The runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. Objects whose lifetimes are managed in this way are called managed data.
The common language runtime makes it easy to design components and applications whose objects interact across languages. Objects written in different languages can communicate with each other, and their behaviors can be tightly integrated. For example, you can define a class and then use a different language to derive a class from your original class or call a method on the original class. You can also pass an instance of a class to a method of a class written in a different language. This cross-language integration is possible because language compilers and tools that target the runtime use a common type system defined by the runtime, and they follow the runtime's rules for defining new types, as well as for creating, using, persisting, and binding to types.
Thus, I am writing my code in C#, using the CLR as my interface. Yes, it does provide conversion as stated, but it does a whole lot more. Something like COM, but better.
As for me creating a .NET 3.5 object? I'm not sure if that is the case, I am attempting to create a C# dll that uses the CLR to allow LV to talk to it.
Allowing me to put a compiled LV app's VI into a subpanel would be useful in that I could try and exeucte the app and if it freezes, kill the app and try again.
Please note that my code currently does work, save for the initial occasional freezing. Once it has been established that the constructor worked, I have no problems after that. Unfortunatly, upgrading to LV 8.6 is not an option.
Well, it appears that it is my development environment that is pooched. I can't even build an exe from it. However, by building it on a different machine, and putting that build on another with a test suite I have successfully and repeatability ran and closed the application without failure for 50+ times, executing the constructor each time and interacting with the control (I made the control using C#, using the .NET 3.5 framework, that is a child of an OCX's window which is a child of a VI's FP). This is a big difference from my development machine which worked a total of 2-3 times before freezing.
I will run it overnight and let you guys know if there was any failure.
Well, I'm not going to get into a debate with what the CLR "is". I'm quite familiar with .NET programming as I've written several C# applications.
As I indicated before, .NET 3.5 is not officially supported in LabVIEW. It may work, it may not. It's definitely not supported in LabVIEW 7. Working on one computer and not another is par for the course. You may wish to change the target framework to .NET 2.0 and recompile your assembly to see if that makes a difference on the computer where you're having problems. Beyond that, there's little more that I can say, and I suspect that NI will probably say the same thing, since .NET 3.5 is not officially supported in LabVIEW. Did I mention that?
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. My app has been executed 1700+ times with no issues.