Assemblies in .NET: What they are and how to manage them

One of the biggest changes in Microsoft architecture with .NET is the concept of assemblies. Although the term "assembly" is new, the concepts that make it a good idea are a lot easier to understand than you might think. Here's a comprehensive introduction to .NET assemblies and how you can make them work for you.

An assembly is the .NET name for an executable file. In other words, a .NET assembly is just the .EXE and .DLL files that are the end result of your program, just like VB 6 and other languages. But this is about the only thing that is the same.

The internal organization of the .NET assembly is entirely different. For example, a .NET executable is actually the source code of an IL (Intermediate Language) program - unless you have used NGEN to create a native code executable. (See the About Visual Basic article about using NGEN, NGEN - When Your Need Is Speed.) When you execute a .NET assembly, you're really just invoking the .NET runtime - called the CLR or Common Language Runtime - to compile the assembly into native code just before it's executed. This is sometimes called the .NET Just-In-Time (JIT) compiler or the "Jitter".

It's easy to take a look at the IL code in your program. Just use the ILDASM program, the IL Disassembler as explained in the About Visual Basic article, The .NET Framework Tools - Introduction and ILDASM.

There are lots of benefits to this new architecture. For example, if your program is a component, you can now "install" it by simply copying it to the new location. There is no need to register components - in VB 6 these are the old COM modules - in the Windows registry. And you no longer have to worry about "breaking" systems because a component was overwritten with an incompatible later version. In the old COM architecture, this problem is called "DLL Hell". .NET architecture can keep track of every component with a unique version number even when they have the same name. You can specify that a program should use a new version of a component or the old one that it was tested with.

Another benefit is that components can be programmed using different languages with complete freedom. After they're compiled into an assembly, they're all just IL programs anyway. Different programmers working on the same project could use different languages with no problems.

(Side note: A programmer who claims that Visual Basic is in some way inferior to any other .NET language is now just demonstrating a lack of technical understanding. The only difference now is how much the language helps you write and debug your program. Visual Basic has always been excellent at this job.)

And still another benefit is that "resources" - such as a graphic file - can be embedded right in the assembly for ease of updating and deploying your system and adding security so the resource doesn't get altered or replaced with something else.

Assemblies can even be created using several individual files if you have that requirement.