Lycangeek

A new home for JJ?

An update for those of you tracking the foster dog situation. Jock Jock is spending some time at a potential adopter and so far things are looking well. Let's hope that it is a wonderful (and permanent) match...

So, what does Beta Release Mean?

Someone forwarded this to me the other day and I just had to share. It is a bit dated on terminology but I think it is quite accurate :)

http://home.tiac.net/~cri/1998/stages.html

Lurk No More!

In case you were wondering, yes - still deep in the bowels of LabVIEW working on the .NET integration. There are a few ideas I've come up with for future blog entries based on my work so far, but I'd really love to hear from you.

So, what kind of stuff would you like to know more about. The following are the types of things that are in my area - or need to learn more about myself - so these ideas I can probably do.

• Interop with LabVIEW (Call Library, CIN, .NET, ActiveX)
• .NET (specifically internals like interop, MSIL, fusion, etc)
• hehe - VXI* (I'm a bit more rusty here, but I was actually the SW group manager for the NI VXI team a few years back)

If there's something about LabVIEW that you would like to know that isn't listed here, let me know that too. I'm trying to get more NI bloggers (there is another NI one out there, btw - Brock Reeve) so extra ideas are good ammunition. If nothing else I might be able to get some guest authors. So, let me have it! Feel free to post a comment or just email me at bloggingbrian@gmail.com.

* I'm actually surprised at how long your work can survive sometimes. When I was first starting in the VXI group (almost a decade ago...scary), I wrote an application note about the VXI triggering ASIC we created - the TIC. I saw a post to the NI DevZone for VXI the other day where the answer referred to my note! So, for history sake, here it is :)

Why debugging is hard

Read through this great blog posting about crashes on Windows. If you've ever had an application bomb out on Windows (yes, yes, the opening is obvious...moving on), you know you'll get one of those "Do you want to report this to MS" dialogs.

I've talked to the folks at Microsoft and it is indeed a very valuable tool. Not only is it anonymous but other companies can register with Microsoft to get the reports on their applications - so please, use the feature!

Anyway, here is a little story about why sometimes developers go bald or insane or whatever when dealing with what should be a very logical little piece of silicon.

http://blogs.msdn.com/oldnewthing/archive/2005/04/12/407562.aspx

Sysinternals Blog!

For those that like the tools from Sysinternals (and if you don't know who they are, you gotta check out there site!), check out the new RSS feeds...

From the newsletter:

1. SYSINTERNALS RSS FEED

Due to popular demand, Sysinternals now has an RSS feed!  I often update tools on the site that don't merit a mention
on the home page, so if you want to keep up to date on these changes, follow this new RSS feed.

3. MARK'S NEW BLOG

Like everyone else on the internet, I've started blogging!  I'm actually enjoying the opportunity to post informal notes
about various software and technology issues and reading responses from you, the readers.  To see my posts so far, visit http://www.sysinternals.com/blog/

The Weak and the Strong

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.

The thing about engineering is that it's a science of trade-offs. So here is a trade-off that we made regarding weakly and strongly named assemblies.

Refresher: A strongly named assembly is digitally signed. Thus if you look at the full assembly name, the token value is non-null. A weakly named assembly is not signed and thus has no token.

Weakly named assemblies have certain advantages. They are easy to create (although Visual Studio makes it pretty easy to do strongly named also) and don't require versioning policies if you change the version number (although Constellation now handles that automatically). However, they are subject to naming collisions.

For example, in directory A I can have foo.dll with version 1.0.0.0. Then, in directory B I can have foo.dll with version 1.0.0.0 - but from a completely different company.

If you create your application like a good .NET citizen this isn't a problem. You keep the DLLs in the same directory as your EXE (or in a single subdirectory such as bin vis-a-vie ASP.NET). Thus you couldn't have two foo.dll's - their names would collide.

This is why 3rd party distributed applications should ALWAYS be strongly named. But of course, this is the real world...

How does this affect LabVIEW? Since we're trying to make it as easy as possible to develop with LabVIEW, we automatically support loading .NET assemblies from directories other than your application's directory (see all the previous postings about Load vs. LoadFrom...ad nauseum).

So, consider, if you will, the following situation:

Developer X creates a VI (viA) that accesses the foo.dll in directory A. Developer Y creates viB that accesses foo.dll in directory B. Each developer tests their VI and blesses it as good.

Now - you get to play lucky developer Z. Your application is going to use those two VIs. You create your application...you press the run button...and BOOM!

Actually, to be fair, if you are in a development environment we are going to warn you a lot earlier than that. However, either way you have a problem.

The issue is that when LabVIEW loads up viA, it tries to resolve the weakly named foo.dll in directory A. Well, Load() fails so we drop back to LoadFrom(), get the assembly and put it in the Load context. Life is good.

Now you try to load viB. We look at the request - hmmmm. An assembly named foo, in a file called foo.dll, with version 1.0.0.0. Well, hell, we already have that. So we pop up a warning (development environment only) and say that your DLL obviously moved to a different directory since you last opened the VI, but don't worry - we found it in the new location.

Thus all your calls in viB are going to go to the wrong assembly. Most likely you're going to get broken arrows (dev env) or an error in your error cluster.

Why don't we just ignore the fact that we've already loaded the DLL? Even .NET Fusion is going to say they are the same thing. Why? Because they are weakly named and based on all we can see they are the same. Remember - we put the foo.dll into the Load context (this solves a host of other problems...remember my comment about tradeoffs?) so when .NET Fusion is asked about foo, version=1.0.0.0 it is going to say - I've got that already.

The solution to this mess is to use strongly named assemblies. If you have access to the source of those assemblies (which I hope since they are weakly named), you can digitally sign them. This means each gets a unique token that allows both LabVIEW and Fusion to see them as completely separate names.

Moral?

Don't do this.

Okay, something better...hmmm...Make sure any assembly that you're going to reference via a path outside your application is strongly named.

You must? No - I hope you noticed that this is a rather contrived example. It isn't likely which is why we decided to let this be the problem child. However, it can happen so be a boy scout - be prepared.

Constellation Clarifications

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.

Some things that were not as clear from the previous post and so this is just some quick clarifications...

Load vs LoadFrom

When I say that LabVIEW uses LoadFrom to load your assemblies if we must use a path, that is correct. However I should point out that because of a little trick we use, they will still end up in the Load context. Thus all assemblies in Contellation are in the Load context.

AppDomain lifetime

This is an important issue if any of the .NET component you use have static data (aka class data). The run mode AppDomain is created when the first VI in your project begins execution. However, the AppDomain is not destroyed until the last VI in your project stops.

Thus consider the case where you have two VIs (viA and viB), one of which increments a static member of a .NET class. Something like

public class A

{

   public static int Counter = 0;

}

Thus if you interactively run viA, which increments the counter and prints out the result, you'll always get an output of 1.

However - if you interactively run viB (which is a long running while loop or some such) and then interactively run viA over and over again, you're going to get 1, 2, 3, 4, etc.

Sometimes this is just a little quirk to remember. Other times (such as initializing your .NET subsystem, registering .NET Remoting objects, etc) it is very important.

Improved Julienne Fries

Looking over that section, I see that I buried a very nice new feature. There I talked about the fact that we now support WinForm controls on the VI front panel, just as we support ActiveX controls. But a little sentence is buried in there - "Getting .NET events to flow into a LabVIEW callback was an interesting challenge".

In Contellation, you can register a VI as a callback for any .NET event. If you are curious about how it works, just take a look at the ActiveX event support - same idea.

.NET Languages

Found this interesting little link. When people say that .NET supports multiple languages, they aren't just saying C# and VB.NET...

http://www.dotnetpowered.com/languages.aspx

MTDW 2005

Well, yesterday was the Mighty Texas Dog Walk for 2005. I haven't yet heard the final number for the walk, but we had beautiful weather and a lot of happy dogs (and people)!

It started fairly well with the alarm going off at 5:30am. Okay, so that isn't so good. But I did wake up and drive down to the Burger Stadium to start setting up the cones. You see, I'm the "Cone Guy". It is official because that is what the police were calling me.

I had 350 cones to place around the stadium and local roads to keep traffic and people away from each other, but it was much smoother this year than last year. For one thing, we had a second pickup truck to help with the cones and watering station supplies. A very good friend of mine came out this year (he has the 2nd pickup) and worked like a champ. We managed to get everything in place by 8:30am. Considering that last year I was trying to get the last of the water stations set up at 9:20 (20 minutes into the walk), this year was amazing.

As far as the walkers were concerned, we had all sorts. Big dogs, little dogs, dogs in carts and even dogs pulling carts. My favorite was a standard poodle that had been dyed the colors of the Jamacian flag - very festive. Yes, yes - temporary dye. No worries.

By noon, we had everything picked up and it was time to scoodle off home for a quick shower and change of clothes. It was time for my nephew's wedding and I was an emergency usher. Again the weather was perfect and the ceromany seemed to go off without a hitch. Of course, I wasn't really involved in the behind the scenes stuff so maybe something was a crisis, but if so they hid it well.

It was a great time, especially because my brother and two sisters, plus associated kids, were there. Even my aunt and cousin from California showed up. It was almost more of a family reunion - and it wasn't even Christmas!

Finally, somewhere in all that excitment, my wife and I were able to celebrate our 10 year wedding anniversary. Interesting that my nephew (12 years younger) and I will share the same anniversary. We made a pact to help remind each other :)

April 1st

Well, it is that special time of year again. I love that my company always puts out a interesting press release. This one isn't too bad, but make sure you check out the list of previous years at the end of the release. Some are better than others.

A bit of personal trivia for you. Tomorrow is my wedding anniversary. In fact, it marks 10 years. The trivia is that 10 years ago, April 2nd fell on a Sunday. Normally the wedding is on a Saturday but I absolutely refused to get married on April Fool's day. I'm just like that.

Another interesting trivia...My nephew is getting married tomorrow (yes, a marriage, the Mighty Texas Dog Walk and my 10 year anniversary - busy day ahead). So he and I will be exactly 10 years apart of marriage. Life is funny...