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

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

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

Необходимо "бросить" его в каталог, где приложение, бывшее нужное в нем, найдет его.

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

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

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

На самом деле нет НИКАКОЙ потребности зарегистрировать dll в.NET на целевой машине.

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

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

Видеть рабочий Пример этого взгляда здесь:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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