DISCLAIMER: All discussion regarding upcoming releases of LabVIEW are not commitments that the final product will be as I describe here. It’s merely what we are thinking at the moment or have implemented to date. Of course, if you have any feedback on this, please post it up or contact me. That is part of the reason for these posts.
So, we’ve talked about assemblies. We’ve talked about how LabVIEW 7 does things. Now it’s time to gaze into the crystal ball and take a look at the upcoming release: Constellation.
I’m letting the cat out of the bag a bit on some new Constellation features to explain everything, but I’ve been assured by marketing I won’t “disappear” after this.
New and Improved
To keep things simple, I’ll start with how things work using LabVIEW in the same way as before (versus projects, which we’ll discuss next). In this case, we cleaned up the algorithm to make it a bit more friendly and robust.
First thing - that Assembly Reference Window is gone! We’ve integrated the .NET nodes into the LabVIEW linker. This means that in addition to the full name of the assembly, we also store the relative path inside the VI (for non-GAC assemblies). Not only does this give you more flexibility, but it also means that if LabVIEW can’t find the assembly, it’ll prompt you with the file dialog to locate it. Nice, huh?
The next thing is that we’ve made the edit mode and run mode behaviors consistent. The algorithm always attempts to load the assembly via a Load() call. If that fails, and we’ve a path, we can fall back to LoadFrom(). This means it’s still best to keep your application and assemblies together, but as long as the files stay in the same relative place during a deployment, it’ll continue to work.
You might wonder why we don’t do a LoadFrom() in the first place if we’ve a path? Well, the answer has to do with how Fusion works in 1.1 of .NET. One key difference between Load() and LoadFrom() is that the first one obeys the .NET version policy files, while the second ignores them. To give you access to the full power of .NET, we are stay in line with the recommended approach as much as possible.
But wait, there’s more
Yep - that’s right. Constellation introduces the concept of projects into LabVIEW. They make it so much easier to do LabVIEW development that I think people will forget (or try to forget) what it was like without them … remember life before Undo?
In a lot of ways, projects are very similar to the project/solution paradigm that you may have seen in Microsoft’s Visual Studio but with some extra twists thrown in for the world of LabVIEW. Well, there are a lot of neat things about projects, but I better stop here until a beta version goes out - I really don’t want to know whether the trunk light goes off when the lid is closed ….
Anyway, the biggest change that projects introduce for .NET integration is that we moved the first-class citizen award from top level VIs to projects. Thus, instead of creating an AppDomain for each top level VI, we create one for each project (actually one per computing machine per project, but we’ll save that for another post - you’re gonna love projects!).
This has one interesting side effect: currently if you do have multiple top level VIs, you can’t share .NET refnums between them, nor use any sort of static state of a .NET class, without a whole lot of work. But now, since all top level VIs in the same project are in the same AppDomain, this works fine.
Also, the AppBase of the domain is set to the home directory of the project. Does this change your deployment? Not necessarily. While projects do let you have your VI’s scattered all over your hard drive if you want, I think most people will keep their main application VIs in same directory as the project they belong to. If that is the case, nothing changes.
What if you don’t? What if your .NET VIs are more of a library shared among different projects? No problem - just keep the relative location of the library VIs the same, and the linker will resolve the assembly – or you can put them in the GAC.
Julienne Fries?
Another change that impacts our assembly view is a new feature -- .NET Controls. Yep, you can now drop a .NET WinForm Control onto a LabVIEW front panel, just like you do with ActiveX controls. Boy - this one was a lot of fun for the team let me tell you. Getting .NET events to flow into a LabVIEW callback was an interesting challenge. But it works!
This actually doesn’t impact the assembly stuff as much as you might think. As with any assembly, you need to follow the rules described above for your controls, but that’s about it. The only real change is that it introduces another AppDomain.
What, another one? Yes, but don’t worry about this one. It’s simply the AppDomain we use to display the .NET controls on the front panel when the VI is not running. This allows you to access the edit mode properties of the control, which still require some .NET code execution.
Spaceman signing off
I figure that is enough for now. I hope you are going to be very pleased with these improvements, as well as all the other new features in Constellation.
Let me know if there is anything else you would like to hear about. It can be either an expansion on something we already discussed, or something totally new – you decide.
Comments