В .NET есть ли необходимость регистрировать DLL?

Обычно достаточно поместить dll в папку вашего приложения на целевой машине.

Если dll должна быть доступна для других приложений, вы можете рассмотреть GAC.

Вам нужно «перетащить» его в каталог, где приложение, которому он нужен, найдет его.

Если существует несколько приложений или вы хотите «перетащить» файл в другое место, а не в каталог приложения, обычно вам нужно либо настроить переменную PATH, либо зарегистрировать сборку в глобальном кэше сборок (GAC).

Приложение может использовать .NET dll, просто располагая его в той же папке, что и приложение.

Однако, если вы хотите, чтобы другие сторонние приложения нашли эту DLL и использовали ее, им также придется включить ее в свой дистрибутив. Это может быть нежелательно.

Альтернативный вариант - зарегистрировать DLL в GAC (глобальном кэше сборок).

Если вы хотите, чтобы доступ к сборке через com +. Примером может быть использование типа, определенного в сборке .NET из приложения, отличного от .NET, такого как приложение winforms VB6.

Если вы планируете получить доступ к сборке из другого приложения .NET, вам не нужно ничего делать. Если ваша сборка имеет сильное имя, вероятно, неплохо было бы поместить его в GAC. В противном случае просто поместите его в каталог приложения, которое будет на него ссылаться.

Я думаю, вы немного путаете. Для того, чтобы использовать dll, никогда не требовалось регистрации.

Для использования dll требуется только загрузить ее (с учетом известного местоположения или если библиотека находится в системном пути) и получить адрес функции, которую вы хотели использовать.

Регистрация dll использовалась при распространении объектов COM или ActiveX, которым необходимо добавить определенные записи в реестр Windows. Чтобы использовать службу COM (например), вам необходимо указать GUID, то есть уникальный идентификатор, который позволяет получить дескриптор библиотеки DLL, которая реализует службу (или предоставить к ней доступ). Иногда вы можете ссылаться на полное имя и получить те же результаты.

Для того, чтобы все это работало, необходимо зарегистрировать dll. Этот процесс «регистрации» просто создает несколько записей в реестре, но в основном эти две: одна связывает GUID с расположением библиотеки dll (чтобы вы могли ссылаться на нее через GUID, не зная, где именно она находится), а вторая связывание полного имени с GUID. Но опять же, это только для объектов COM или ActiveX.

Когда вы разрабатываете приложение в .NET, библиотеки, на которые есть ссылки в вашем проекте, автоматически загружаются, когда они необходимы, и вам не нужно беспокоиться о их местонахождении или загрузке. Для этого платформа проверяет два местоположения ссылочных библиотек.

• Первое местоположение - это путь к приложению.
• Второе место - GAC.

GAC (Global Assembly Cache) позволяет вам эффективно регистрировать dll для использования во всей системе и работает как эволюция старого механизма регистрации.

Так что в основном вам просто нужно поместить dll в ту же папку приложения.

Одним из главных преимуществ .NET для платформы Windows, когда он появился на сцене, является то, что по умолчанию библиотеки DLL сборки .NET не нужно регистрировать и могут быть использованы частным образом приложением, просто поместив их в один и тот же папку как EXE-файл. Это был большой шаг вперед, потому что он позволил разработчикам избежать адской битвы с DLL / COM.

Совместно используемые модули DLL / COM оказались одной из величайших ошибок проектирования Windows, поскольку они приводили к нестабильности приложений, устанавливаемых пользователями. Установка нового приложения вполне могла испортить приложение, которое работало нормально, потому что в новом приложении были представлены новые версии общих модулей DLL / COM. (На практике оказалось, что разработчикам слишком сложно правильно управлять детализированными зависимостями версий.)

Одно дело - управлять версиями модулей с помощью системы репозитория сборки, такой как Maven. Maven работает очень хорошо, делая то, что делает.

Однако совсем другое дело - решать эту проблему в среде выполнения конечного пользователя, охватывающей миллионы пользователей.

.NET GAC ни в коем случае не является достаточным решением этой извечной проблемы Windows.

Сборки DLL, потребляемые частным образом, по-прежнему являются бесконечно предпочтительными. Это простой способ сделать это, поскольку в наши дни дисковое пространство чрезвычайно дешево (в наши дни у Фрая можно купить терабайтный диск примерно за 100 долларов). Совместное использование сборок с другими продуктами ничего не даст - и все же репутация компании может потеряться, когда дела бедного пользователя пойдут плохо.

На самом деле нет необходимости регистрировать dll в .NET на целевой машине.

Если вы ссылаетесь на .dll в своем приложении, щелкните ссылку .dll под ссылками в вашем проекте, просмотрите свойства и установите для параметра Isolated значение TRUE.

Теперь это автоматически включит эту DLL в ваш проект, и ваше приложение будет использовать копию .dll, включенную в ваш проект, без необходимости регистрировать ее в целевой системе.

Чтобы увидеть рабочий пример этого, посмотрите здесь:

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

Рассматриваемая .dll должна быть зарегистрирована в системе, в которой вы создаете свое приложение, чтобы это работало должным образом. Однако, как только вы создадите свой проект, вам не нужно будет регистрировать соответствующую DLL в какой-либо системе, в которой вы развертываете свое приложение или программу.

Дополнительным преимуществом использования этого метода является то, что даже если в будущем другая .dll будет зарегистрирована с тем же именем в рассматриваемой целевой системе, ваш проект будет продолжать использовать .dll, с которой вы развернули. Это очень удобно, если .dll имеет много версий, и вы хотите сохранить некоторую стабильность, например, при использовании той, с которой вы тестировали, но все другие приложения будут использовать зарегистрированный .dll, если они также не используют метод isolated = true.

Приведенный выше пример является одним из тех случаев, существует много версий Skype4COM, который представляет собой .dll Skype API и может часто меняться.

Этот метод позволяет в приведенном выше примере использовать .dll API, с которым был протестирован проект, каждый раз, когда пользователь устанавливает новую версию Skype, возможно, что будет установлена ​​измененная версия этой .dll.

Кроме того, есть некоторые клиенты Skype, которые не устанавливают этот .dll, например, бизнес-версия клиента Skype меньше и не включает этот .dll, поэтому в этом случае проект не завершится с ошибкой на этом .dll отсутствует и не регистрируется, потому что он включен в проект как isolated = true.