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

Ответ 1

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

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

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

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

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

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

GAC (глобальный кэш сборок) позволяет эффективно регистрировать DLL, которая будет использоваться во всей системе, и работает как эволюция старого механизма регистрации.

Таким образом, в основном вам просто нужно поместить DLL в ту же папку приложения.

Ответ 2

Вам нужно "отбросить" его в каталог, в котором оно найдет его.

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

Если вы ссылаетесь на .dll в своем приложении, нажмите на ссылку .dll по ссылкам в вашем проекте, посмотрите на свойства и установите Изолированные на ИСТИННО.

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

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

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

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

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

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

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

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

Ответ 7

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

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

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