LabVIEW
Can LabVIEW create .NET managed assemblies
@Kyle97330 wrote:
Pretty sure this is what you're looking for
It doesn't mention 'managed' though...
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
@Kyle97330 wrote:
Pretty sure this is what you're looking for
It doesn't mention 'managed' though...
But what would be an unmanaged .Net assembly? Unmanaged means in .Net normally code that is not running in the .Net CLR such as the WinAPI. A .Net assembly generally always executes in managed mode although you can have mixed mode assemblies that contain internally unmanaged code.
However a LabVIEW .Net assembly is always in native code, which means only executable for the processor architecture that the creating LabVIEW version supports, since LabVIEW creates directly native machine code and not .Net IL (intermediate language) code.
So does the .NET assembly wrapper around the LV compiled code make the assembly managed? Or is it still unmanaged because of the compiled code?
Even after reading this https://stackoverflow.com/questions/3563870/difference-between-managed-and-unmanaged, it's not really clear. Guess we're in a corner case.
I'm leaning towards "unmanaged". Not because of the compiled code in the assembly. It is possible (probably pretty easy) to make a LV .NET assembly that doesn't manage it's own memory. E.g. it would leak memory. Not sure again if that means all LV .NET assamblies are unmanaged, or that you can create both...
Well I guess it depends what you consider managed. Some people only seem to allow assemblies to be called managed if they are fully in IL code, which can then be compiled JIT to the target platform. I personally think that this was not the original intention, but that managed means that the code follows a certain protocol to manage its objects according to rules laid out by the .Net standard and that any memory allocated within such objects is either a proper .Net object itself or fully managed by the object internally according to its own lifetime. According to this definition a LabVIEW .Net assembly would be fully managed. According to the first definition it wouldn't be, as LabVIEW does not create IL code.
I have this old book, that defines "managed". The book is called :Reversing: Secrets of Reverse Engineering" (no comments on that)...
Managed Code:
Managed code is any code that is verified by the CLR in runtime for security, type safety, and memory usage.
Is goes on for a while...
I'm leaning towards LV .NET assemblies being managed, iff written correctly. Same goes for any .NET assembly, as they can all contain external calls.
It's definitely possible, although not my prefered mode. I find .Net adds another serious complexity to the whole picture so I tend to avoid it whenever possible.
Also note that there are certain limits to what you can do in LabVIEW in respect to .Net. For instance a LabVIEW .Net assembly always implements an object that is directly inheriting from Object. There is no way to have it inherit from anything else. Also LabVIEW does not support Generics, so any object method from a .Net assembly that uses Generics in its parameters or type definition will be not accessible in LabVIEW.
But if you can live with these limitations then it's a viable solution to mix and match both worlds at will, but it will definitely add complexity to your application both during development time as well as at runtime, since the system now not only needs to initialize one heavy handed managed runtime environment, but rather two.
Yes I consider LabVIEW also as a managed environment as it has very specific rules about how its "objects" need to be allocated and managed during the lifetime of an application, although as long as you stay in the LabVIEW diagram and don't dive into external code you notice very little of those rules.
