Refnums in LabVIEW are not a new thing - they represent some external resource that must be tracked and released when you're finished with it. The most common example is the file refnum, created whenever you open a file.
For those programming .NET in LabVIEW, refnums are your constant companion. We convert what .NET data types we can into native types, but there are simply too many types in .NET that have no correlation. So, you get refnums.
But, just like files, you need to be sure to close the refnum when your done with it, or you'll get a memory leak. Let's take a look at when you do and don't need to close a .NET refnum.
To help explain the rules, I'm going to refer to the image you see here on the page. It's got several examples that I hope demonstrate the do's and don'ts.
Let me start with the basic rule - if a .NET object is put onto a wire for the first time (as far as LabVIEW is aware of), then it generates a new refnum. If it's a new refnum, it needs to be closed.
So, lets look at the first and second examples. Here is a very simple bit of code that creates a .NET object via the constructor node. Obviously, if you create an object, its refnum needs to be closed (as shown). Notice that the code also calls a method (GetType) which returns another .NET object. In the first example, however, we don't close that refnum. Why? Because LabVIEW detects that it's never used - no wire is connected to the terminal. In that case, we can handle the cleanup automatically. But, as the second example shows, once you've wired it, you need to close it.
The next example is one of a pattern that often has memory leaks in it. In this case, you're iterating through the elements in an object via a .NET enumerator. The most common mistake is to forget to close reference returned from Current.
The next two show actual memory leaks - probably the most common type I've seen. Because many .NET objects are simply returned from one call, only to be passed into another, it's easy to forget that they need to be closed. The refnum from GetType is on a wire for the first time, so according to the rule, must be closed. Same with the static property, CurrentDomain. The fact that they only travel a few millimeters doesn't matter :)
The last example shows the corollary to the rule - when it's known to LabVIEW that it isn't a first time object. Consider a cast of an object from one type to another. For .NET, we provide a couple of nodes that convert a refnum type definition from one type to another - but we know that's what we are doing. We, meaning LabVIEW, are well aware that the actual object going into the left terminal is the same one coming out the right side. It's a cast operation after all. Therefore, you don't need to close both types of refnums. If you were to drop down probes on the refnum before and after, you'd see that the value of the refnum was the same on each side - a good indication that it's the same one.
So, there you go...hopefully some simply guidelines to know when to close the refnum. The good news is that we track all refnums internally, so when your application stops running, we'll clean up after any leftover refnums. But if your application is long running, you may run out of memory before then - so be careful.