Unmanaged Assemblies

If you're looking closely, you might think that unmanaged assemblies is a contradiction in terms. Assemblies are generally considered .NET constructs, and the term unmanaged means Not .NET. However, with the introduction of Visual Studio.NET 2005, Microsoft has extended the concept to include your regular old C DLLs.

Let's first take a look at what this new concept is, and then we'll look at how this impacts LabVIEW developers.

If you install VS.NET 2005, you'll find a new directory in your Windows home directory, such as

c:\Windows\WinSxS

which stands for Side-by-Side - a term that should be familiar to those with a lot of experience with .NET assemblies. SxS allows you do create dependencies, not just on the name of the DLL, such as MSVC.dll, but also on the version of that DLL (think strongly named .NET assemblies).

The idea, as in .NET, is that you can have two applications both dependent on a system library. Now let's say that one of those two applications is upgraded, and in the process, a new version of that system library is installed. Well, the new application is happy, because it's running with the version of the library it was tested with. However, the other application, the one that wasn't upgraded, is now off a cliff. Will it still work? Maybe. Maybe not.

Let's say it doesn't work anymore. What are you going to do? Well, you can reinstall the application, which results in the original version of the system library being installed. Now the upgraded application stops working.

This, my friends, is what is known as DLL Hell, and basically means you're stuck.

So, what does WinSxS do for you? Let's take a look at an example entry in that directory.

<DIR>          x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd

Notice that the MSVC80 C runtime library isn't just sitting around like the old days, as in c:\Windows\MSVCRT80.dll. Instead, that DLL now rests in a directory that contains not only the name, but the version, the public key token (to prevent name collisions) and the information that it's the x86 (versus x64) version.

This is wonderful. Now an application can be very specific about exactly what components it wants, and be assured it is going to get what it needs. So, what's the problem?

The problem is how you now must load these libraries. As you can probably guess, you can just do the old LoadLibrary(filename) approach - what is the filename? What is the path? How do I get all of this into the PATH environment variable? Obviously, you can't.

I'm not going to go into the details of how you build on of these guys - that is a very advanced topic. However, just upgrading your old C++ code to VS.NET 2005 is going to require that you deal with this.

So, next post, I'll explore what happens to LabVIEW CINs built with VS.NET 2005.