Lycangeek

Chance's Vet Trip

Yesterday was Chance's first trip to the vet since he came into our home. I'm pleased to report that he handled the trip very well. I was told that the first time he was brought, he was so scared he wouldn't come out of the crate and it had to be dismantled. Yesterday, though, I put the crate on the ground, opened the door and he walked out. A bit nervous but I'll take it :)

He even walked (in stages) across the parking lot to the front door. I figured that was victory enough.  I didn't want to make him walk through the door into the waiting room with the other dogs and cats, so I picked him up.

He handled the vet check very well - laid (fairly) calmly on the exam table. The vet reported no problems - his sores and scabs were healing well, good heartbeat and overall color. He has also went from 12lbs to 14.5lbs in a week - which is a good gain for a short time - but he still has a way to go.

Most importantly, he came up to me last night for more pets, so apparently he wasn't holding a grudge :)

Podcasting

Some of you may have heard of the new Podcasting concept. This is where the person records an audio track and then makes it available for download as an .mp3. I've heard that the newest version of Apple's iTunes now has a catalog for the thousands of pod-sites out there.

Personally, I'm very interested in this because I think it can be another great way of getting LabVIEW users more information from NI - and specifically from the developers (such as my humble self - lol).

Anyway, JR Allen here at National Instruments is trying to get this next stage (after blogs) off the ground. Check out his request for your help here.

Sheltie Rescue

I just realized that I've been talking about my foster dogs but haven't been pushing our site. So, here's my quick commercial for Austin Sheltie Rescue. There, that wasn't so painful was it?

Chance Update - The first pet

Every day with Joey Chance is another step forward.  When you're working with a dog that has been this traumatized you must set your expectations very low for the rate of progress, but I've been very pleased so far.

Welcome Ryan

We have convinced another LabVIEW'er here at NI to join in the blog effort - Ryan Pollack. Check out his new site...

Second Chance

A few days ago we received our new foster dog from Sheltie Rescue, and this is going to be one of the hardest ones to let go. Joey Chance, the sheltie, was found hiding in a drainage ditch on Monday and was nothing but skin and bones.

LabVIEW and .NET 2.0

As some of you may know, Microsoft has announced the final ship date for the whole .NET 2.0 kit (Visual Studio 2005, SQL Server 2005, etc) as November 7th. In addition, there have been some posts on devzone regarding LabVIEW hanging if the .NET 2.0 beta is installed. So, I thought I'd take a moment and cover the state of the union for LabVIEW and the next release of .NET.

LabVIEW 7.x

Unfortunately, as some people have discovered, LabVIEW 7 is not compatible with .NET 2.0. This has to do with the fact that Microsoft has completely redesigned the way the framework is installed (specifically the GAC) and this has broken the code that provides you with the list of installed assemblies. There is currently no workaround for this problem other than to not install .NET 2.0.

However, I'm working on a patch to LV 7.1.1 that'll fix this problem. If you need this patch when it becomes available, please let me know (either post a comment or shoot me an email to bloggingbrian@gmail.com). Once the patch is ready, it'll behave as described in Constellation below.

Note that this is a patch to LV 7.1.1 only (which is a free upgrade available to 7.1 users). If you have an earlier version you must first upgrade or wait for the Constellation release.

Constellation

As you might expect, supporting .NET 2.0 is a requirement for Constellation and so you can have either or both .NET 1.1 and 2.0 installed. However, this raises an interesting question of which one you get if both are installed. So, here you go...

LabVIEW uses the C++ .NET feature of IJW ("it just works" - we didn't come up with that, it's classic MS tech-marketing) to bring up the .NET runtime (a.k.a the CLR) and talk back and forth between the LabVIEW native code and the LabVIEW .NET code.

Because of that, the version of the CLR that executes under LV is always the most recent CLR installed on your machine. You can read this article to get the complete details - see the Application Load Mechanisms and Possible Issues section. We are the third row in the table.

Picking the .NET Framework

In general, this should not matter to most LV .NET users. Running under the 2.0 CLR is pretty much like running under the 1.1 CLR so your application should not care. However, there are some breaking changes between 1.1 and 2.0 that could cause you some problems depending on what parts of .NET you are using in your application. Again, the article goes into the full details on that.

So, what happens if you absolutely need to run with the 1.1 CLR? Well, Microsoft has provided a configuration setting that forces a native application like LabVIEW to load a specified version of the CLR. For the LV development environment, you need to create a file called LabVIEW.exe.config (capitalization is optional) in the same directory as the EXE itself. Put the following into the file:

<configuration>
   <startup>
      <requiredRuntime version="v1.1.4322"/>
   </startup>
</configuration>

Now LabVIEW is going to run with the 1.1 version of .NET even if .NET 2.0 is installed. Obviously, you'd better have installed 1.1  :)

What about built applications? The same general rule applies - you need the requiredRuntime key put into your application's configuration file. See this previous post about how to create .NET configuration files for your built application.

What if your built component is a DLL instead of an EXE? Well, that gets a bit more complicated. The short answer is that the EXE that is loading your DLL must have the above configuration file.

The longer answer: The requiredRuntime key must be loaded before the CLR version is picked. Unfortunately, the DLL's configuration file isn't processed until after the CLR is loaded. This is because LV puts the configuration file into the AppDomain for you - .NET doesn't support DLL-level config files. But by this point the CLR is already up and running so....

Longer answer addendum: Another point to consider is that the CLR is loaded by the first part of any application to request .NET - you only get one CLR per process. Therefore, you could consider two LV DLLs, one that wants 1.1 and one that wants 2.0. Well, that's going to be a problem if the DLL configuration file picked the CLR. Which CLR you got would depend on the load order. Therefore, the application is always the one that picks the CLR version.

Again - this is only a problem IF you care which version of the CLR is loaded. Almost every application out there should not care. Almost... :)

LOTR and lots of meat

Interesting title I imagine but they're related in that it's what happened to me this weekend.

I took a trip with my wife and some friends down to Houston to see the Lord of the Rings exhibit at the Houston Museum of Natural Science (why it's there I have no idea...), which was absolutely incredible.

At first I thought I'd been ripped off as we wandered slowly through the line which contained several photos and one miniature - but it turned out this was just the preshow "waiting for hours" line. Luckily the crowd wasn't that bad so it was more of a slow shuffle. Then the hall opened into a much larger area containing an amazing array (photos are not mine, just found them on the web) of costumes, miniatures, documentaries and models.

After the exhibit, it was off to dinner (not counting the stop at the gift shop but let's not go there...again anyway...). If you have never been, I highly recommend Fogo de Chao for an excellent meal. It is like a cascade of wonderfully cooked meat pouring over your table. Okay, that image may not be great but trust me - the food is. Even if you are vegetarian you should go for the salad bar (which non-vegs should avoid to save room) - check out the image (top banner)! I'll warn you that it is not inexpensive...let's face it, it is expensive, but well worth it for special occasions.

.NET Config Files

.NET provides a mechanism to input runtime information into an application via an XML configuration file. These are used for a variety of reasons, such as picking a logging level or providing networking information (hostname, port, IP, protocol, etc). LV itself doesn't need or use these configuration files itself but your application may want them.

For example, if you want to use .NET remoting to communicate to another object in a different AppDomain, process or machine, you typically aren't going to want to hardcode all of that information in your VI. Put it into the configuration file.

Under .NET, the configuration file is named after the executable (for example, notepad.exe.config) and is in the same directory as the program. For LabVIEW, obviously, that doesn't work as well so we have some different settings for where to find the configuration file.

LabVIEW 7.x

As described in the LV User's manual, you can create a configuration file for any VI by naming it after the VI, such as add.vi.config.

However, the configuration file for a VI is only loaded if the VI is run as a top level VI. If it's called as a subVI, the configuration file for the subVI is ignored. This is due to the fact that configuration files must be specified when the AppDomain is created, and as I've discussed in previous posts, that's when the top level VI runs.

In general this shouldn't matter for most applications, but it's something to remember...especially when running subVIs independently for debugging or other reasons.

Note that if you are using a built EXE, then the configuration file follows the .NET rules (add.exe.config).

Constellation

If you read my post on Constellation then you know that we have changed the rules of when AppDomains are created for VIs. This is a big step forward, I believe, as it allows for the sharing of .NET references across VIs much more easily. But it does mean that some things must change.

First and foremost is the requirement that you use a project to access the configuration file. This was a difficult requirement to finally decide on but if you think about it, it does make sense. In Constellation, rather than being tied to a VI, the AppDomain is either global (non-project world) or per-project. Since there's no "home" for the global case, it's kinda hard to create a configuration file in it.

Thus the naming rules for Constellation are as follows...

• For Projects, it is named after the project (MyApp.lvproj.config)
• For Built EXEs, things haven't changed - MyApp.exe.config
• For Built DLLs, you can now create configuration files for each DLL - MyApp.dll.config. As you'd expect, you put this into the same directory as the DLL.

More reasons to dislike LoadFrom

Readers of my blog should recognize by now that I'm not a big fan of LoadFrom assemblies. If you haven't read my previous notes on them, you can find a basic background here, an explaination of LV 7 and assemblies here, and the future plans here.

I'd hoped that we could've gotten rid of the LoadFrom context completely in Constellation, but apparently we can't. Our various techniques didn't work and word from Microsoft is that you just can't avoid the context if the assembly isn't in the GAC or probe path.

So, as I mentioned in the previous posts, let me put out the plea again to please keep your assemblies in the GAC or in the directory of the VI (7.x) or project (Constellation).

Why am I bringing this up? Well, here are a couple of new blog posts (here and here) by a developer at Microsoft on more nastiness regarding the LoadFrom context. Let's just all agree we don't want to go there...