В .NET нужно ли регистрировать DLL?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы ссылаетесь на .dll в своем приложении, щелкните указанную .dll в разделе ссылок в вашем проекте, просмотрите свойства и установите для параметра «Изолированный» значение «ИСТИНА».

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

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

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

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

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

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

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

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

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

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

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