[ACCEPTED]-In .NET, is there a need to register the DLL?-dllregistration

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

To see 33 a working Example of this look here:

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

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

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

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

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

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

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

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

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