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

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 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

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).

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.