In .NET, is there a need to register the DLL?

Question

Is it necessary to register a compiled DLL (written in C# .NET) on a target machine.

The target machine will have .NET installed, is it enough to simply drop the DLL onto the target machine?

Answer 1

I think you're confusing things a little. Registering a dll has never been needed in order to use it.

Using a dll requires only to load it (given a known location or if the library is in the system path) and get the address of the function you wanted to use.

Registering the dll was used when distributing COM or ActiveX objects which need to add certain entries to the windows registry. In order to use a COM service (for example) you need to reference a GUID — that is, a unique identifier — which allows you to get a handle to the dll that implements the service (or provide access to it). Sometimes you can make reference to a fully-qualified name and get the same results.

In order for all that to work the dll needed to be registered. This "registration" process just creates several entries in the registry, but mainly these two: one associating a GUID with the location of the dll (so that you can reference it through the GUID without knowing where is it exactly located) and a second one associating the full name with the GUID. But again, this is just for COM or ActiveX objects.

When you develop an application in .NET, the libraries referenced on your project are automatically loaded when they're needed without you having to worry about locating or loading them. In order to to that, the framework checks two locations for the referenced libraries.

• The first location is the application path.
• The second location is the GAC.

The GAC (Global Assembly Cache) allows you to effectively register a dll to be used throughout the system and works as an evolution of the old registering mechanism.

So basically you just need to put the dll in the same folder of the application.

Answer 2

You need to "drop" it into a directory where the application needing it will find it.

If there are multiple applications, or you want to "drop" the file somewhere other than the application directory, you generally need to either adjust the PATH variable, or register the assembly in the Global Assembly Cache (GAC).

Answer 3

It is usually enough to drop the dll into the folder of your app on the target machine.

If the dll must be available to other applications then you may want to consider the GAC.

Answer 4

If you wish to access the assembly via com+. An example would be using a type defined in a .NET assembly from a non .NET application, such as a VB6 winforms app.

If you plan on accessing the assembly from another .NET application, you don't have to do anything. If your assembly has a strong name, it probably is a good idea to drop it in the GAC. Otherwise, just drop it in the directory of the application that will be referencing it.

Answer 5

One of the great selling points of .NET for the Windows platform when it came onto the scene is that by default, .NET assembly DLLs don't have to be registered and can be consumed privately by an application by merely putting them in the same folder as the EXE file. That was a great stride forward because it enabled developers to avoid the fray of DLL/COM hell.

Shared DLL/COM modules proved to be one of the greatest design mistakes of Windows as it lead to instability of applications that users installed. Installing a new app could well screw up an app that had been working just fine - because the new app introduced newer versions of shared DLL/COM modules. (It proved in practice to be too much of a burden for developers to properly manage fine-grained version dependencies.)

It's one thing to manage versions of modules with a build repository system like Maven. Maven works extremely well doing what it does.

It's an entirely different matter, though, to deal with that problem in an end-user runtime environment spread across a population of millions of users.

The .NET GAC is by no means a sufficient solution to this age-old Windows problem.

Privately consumed DLL assemblies continue to be infinitely preferable. It's a no-brainer way to go as diskspace is extremely cheap these days (~$100 can by a terabyte drive at Fry's these days). There is nothing to be gained with sharing assemblies with other products - and yet company reputation to loose when things go south for the poor user.

Answer 6

Actually there is NO need to register a dll in .NET on the target machine.

If you reference a .dll in your application, click on the referenced .dll under references in your project, look at the properties and set Isolated to TRUE.

This will now automatically include this .dll in your project and your application will use the copy of the .dll included in your project without any need to register it on the target system.

To see a working Example of this look here:

http://code.msdn.microsoft.com/SEHE

The .dll in question will need to be registered on the system where you build your application for this to work properly. However once you build your project, there will not be any need to register the .dll in question on any system you deploy your application or program.

An additional benefit of using this method, is that even if in the future, another .dll is registered with the same name on the target system in question, your project will continue to use the .dll you deployed with. This is very handy where a .dll has many versions and you wish to maintain some stability, like using the one you tested with, yet all other applications will use the registered .dll unless they use the isolated = true method as well.

The example above is one of those cases, there are many versions of Skype4COM which is a Skype API .dll and can change often.

This method allows the above example to use the API .dll that the project was tested with, each time a user installs a new version of Skype, it is possible that a modified version of this .dll is installed.

Also, there are some Skype clients that do not install this .dll, the business version of the Skype client for example, is smaller, and does not include this .dll, so in this case, the project does not fail on that .dll missing and not being registered because it is included in the project as isolated = true.

Answer 7

An application can use a .NET dll by simply having it present in the same folder with the application.

However if you want other third-party applications to find the DLL and use it they would also have to include it in their distribution. This may not be desirable.

An alternative is to have the DLL registered in the GAC (Global Assembly Cache).