C# 在.NET中，是否需要注册DLL？

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

提问by Helios

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

是否有必要在目标机器上注册一个已编译的 DLL（用 C# .NET 编写）。

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

目标机器将安装 .NET，简单地将 DLL 放到目标机器上就足够了吗？

采纳答案by Jorge Córdoba

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

我觉得你有点把事情搞糊涂了。从来不需要注册一个dll来使用它。

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.

使用 dll 只需要加载它（给定已知位置或库是否在系统路径中）并获取您想要使用的函数的地址。

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.

在分发需要将某些条目添加到 Windows 注册表的 COM 或 ActiveX 对象时，使用了注册 dll。为了使用 COM 服务（例如），您需要引用一个 GUID — 即唯一标识符 — 它允许您获取实现该服务的 dll 的句柄（或提供对它的访问）。有时，您可以引用完全限定的名称并获得相同的结果。

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.

为了使所有这些工作都需要注册 dll。这个“注册”过程只是在注册表中创建了几个条目，但主要是这两个：一个将 GUID 与 dll 的位置相关联（以便您可以通过 GUID 引用它而不知道它的确切位置）和第二个将全名与 GUID 相关联。但同样，这仅适用于 COM 或 ActiveX 对象。

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.

当您在 .NET 中开发应用程序时，您项目中引用的库会在需要时自动加载，而您无需担心定位或加载它们。为此，框架会检查引用库的两个位置。

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

• 第一个位置是应用程序路径。
• 第二个地点是 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.

GAC（全局程序集缓存）允许您有效地注册要在整个系统中使用的 dll，它是旧注册机制的演变。

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

所以基本上你只需要把 dll 放在应用程序的同一个文件夹中。

回答by Ed Guiness

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

通常将 dll 放入目标计算机上的应用程序文件夹中就足够了。

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

如果 dll 必须可用于其他应用程序，那么您可能需要考虑GAC。

回答by Lasse V. Karlsen

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

如果有多个应用程序，或者您想将文件“放置”到应用程序目录以外的其他位置，您通常需要调整 PATH 变量，或者在全局程序集缓存 (GAC) 中注册程序集。

回答by AnthonyWJones

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

应用程序可以使用 .NET dll，只需将其与应用程序放在同一文件夹中即可。

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.

但是，如果您希望其他第三方应用程序找到该 DLL 并使用它，他们也必须将其包含在他们的发行版中。这可能是不可取的。

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

另一种方法是在 GAC（全局程序集缓存）中注册 DLL。

回答by AnthonyWJones

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.

如果您希望通过 com+ 访问程序集。一个示例是使用在非 .NET 应用程序（例如 VB6 winforms 应用程序）的 .NET 程序集中定义的类型。

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.

如果您计划从另一个 .NET 应用程序访问程序集，则无需执行任何操作。如果您的程序集具有强名称，则最好将其放入 GAC 中。否则，只需将其放在将引用它的应用程序目录中。

回答by RogerV

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.

.NET 在 Windows 平台上出现时的一大卖点是，默认情况下，.NET 程序集 DLL 不必注册，应用程序只需将它们放在相同的目录中即可私下使用。文件夹作为 EXE 文件。这是一个巨大的进步，因为它使开发人员能够避免 DLL/COM 地狱的竞争。

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

共享 DLL/COM 模块被证明是 Windows 最大的设计错误之一，因为它会导致用户安装的应用程序不稳定。安装一个新的应用程序很可能会把一个运行良好的应用程序搞砸——因为新的应用程序引入了更新版本的共享 DLL/COM 模块。（实践证明，对于开发人员来说，正确管理细粒度版本依赖项的负担太大了。）

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

使用像 Maven 这样的构建存储库系统来管理模块的版本是一回事。Maven 在做它所做的事情时工作得非常好。

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.

.NET GAC 绝不是解决这个古老的 Windows 问题的充分解决方案。

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.

私人使用的 DLL 程序集仍然是无限可取的。这是一个很简单的方法，因为现在磁盘空间非常便宜（现在 Fry's 的一个 TB 驱动器大约可以卖 100 美元）。与其他产品共享组件没有任何好处 - 然而，当情况恶化时，可怜的用户会失去公司的声誉。

回答by RogerV

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

实际上不需要在目标机器上的 .NET 中注册一个 dll。

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.

如果您在应用程序中引用了 .dll，请单击项目中引用下的引用 .dll，查看属性并将隔离设置为 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.

现在，这将自动将此 .dll 包含在您的项目中，并且您的应用程序将使用项目中包含的 .dll 副本，而无需在目标系统上注册它。

To see a working Example of this look here:

要在此处查看此外观的工作示例：

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

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.

有问题的 .dll 需要在您构建应用程序的系统上注册才能正常工作。但是，一旦您构建了您的项目，就不需要在您部署应用程序或程序的任何系统上注册有问题的 .dll。

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.

使用此方法的另一个好处是，即使将来在相关目标系统上注册了同名的另一个 .dll，您的项目也将继续使用您部署时使用的 .dll。当 .dll 有许多版本并且您希望保持一定的稳定性时，这非常方便，例如使用您测试过的那个，但所有其他应用程序将使用注册的 .dll，除非它们也使用隔离 = true 方法。

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

上面的例子是其中一种情况，Skype4COM 有很多版本，它是一个 Skype API .dll，可以经常更改。

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.

此方法允许上述示例使用测试项目的 API .dll，每次用户安装新版本的 Skype，都可能安装此 .dll 的修改版本。

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.

另外，有一些Skype客户端没有安装这个.dll，例如Skype客户端的商业版，体积更小，不包含这个.dll，所以在这种情况下，项目不会在那个.dll上失败丢失且未注册，因为它作为隔离 = true 包含在项目中。