Es necesario registrar una DLL compilada (escrita en C# .NET) en una máquina de destino.En .NET, ¿hay una necesidad de registrar la DLL?
La máquina de destino tendrá .NET instalado, ¿es suficiente simplemente colocar la DLL en la máquina de destino?
Creo que estás confundiendo las cosas un poco. El registro de un dll nunca se ha necesitado para poder usarlo.
El uso de un dll solo requiere cargarlo (dada una ubicación conocida o si la biblioteca está en la ruta del sistema) y obtener la dirección de la función que desea utilizar.
El registro de la dll se utilizó al distribuir objetos COM o ActiveX que necesitan agregar ciertas entradas al registro de Windows. Para utilizar un servicio COM (por ejemplo) necesita hacer referencia a un GUID —, es decir, un identificador único — que le permite obtener un control para el dll que implementa el servicio (o proporcionar acceso a él). A veces puede hacer referencia a un nombre completamente calificado y obtener los mismos resultados.
Para que todo eso funcione, el dll debe estar registrado. Este proceso de "registro" solo crea varias entradas en el registro, pero principalmente estas dos: una asociando un GUID con la ubicación del dll (para que pueda referenciarlo a través del GUID sin saber exactamente dónde se encuentra exactamente) y un segundo asociando el nombre completo con el GUID. Pero nuevamente, esto es solo para objetos COM o ActiveX.
Cuando desarrolla una aplicación en .NET, las bibliotecas a las que se hace referencia en su proyecto se cargan automáticamente cuando las necesita sin tener que preocuparse de ubicarlas o cargarlas. Para eso, el marco verifica dos ubicaciones para las bibliotecas a las que se hace referencia.
El GAC (Global Assembly Cache) le permite registrar efectivamente un dll para ser utilizado en todo el sistema y funciona como una evolución del antiguo mecanismo de registro.
Así que, básicamente, basta con poner el dll en la misma carpeta de la aplicación.
Por lo general, es suficiente para colocar el dll en la carpeta de su aplicación en la máquina de destino.
Si el dll debe estar disponible para otras aplicaciones, entonces es posible que desee considerar el GAC.
Debe "dejar caer" en un directorio donde la aplicación que lo necesite lo encontrará.
Si hay varias aplicaciones, o si desea "soltar" el archivo en algún lugar que no sea el directorio de la aplicación, generalmente necesita ajustar la variable PATH o registrar el ensamblado en el Caché de ensamblaje global (GAC).
Una aplicación puede usar .NET dll simplemente con tenerla presente en la misma carpeta que la aplicación.
Sin embargo, si desea que otras aplicaciones de terceros encuentren la DLL y la utilicen, también deberían incluirla en su distribución. Esto puede no ser deseable.
Una alternativa es tener la DLL registrada en el GAC (Global Assembly Cache).
Si desea access the assembly via com+. Un ejemplo sería usar un tipo definido en un ensamblado .NET desde una aplicación que no sea .NET, como una aplicación de formas de pago VB6.
Si planea acceder al ensamblaje desde otra aplicación .NET, no tiene que hacer nada. Si su ensamblado tiene un nombre fuerte, probablemente sea una buena idea colocarlo en el GAC. De lo contrario, simplemente colóquelo en el directorio de la aplicación que lo hará referencia.
Uno de los mejores puntos de venta de .NET para la plataforma de Windows cuando entró en escena es que, de manera predeterminada, las DLL de ensamblaje de .NET no tienen que registrarse y pueden ser consumidas de forma privada por una aplicación simplemente poniendo ellos en la misma carpeta que el archivo EXE. Eso fue un gran paso adelante porque permitió a los desarrolladores evitar el enfrentamiento de DLL/COM infierno.
Los módulos DLL/COM compartidos demostraron ser uno de los mayores errores de diseño de Windows, ya que conduce a la inestabilidad de las aplicaciones que los usuarios instalan. La instalación de una nueva aplicación podría arruinar una aplicación que funcionaba bien, ya que la nueva aplicación presentaba versiones más recientes de módulos DLL/COM compartidos. (Demostró en la práctica ser una carga excesiva para que los desarrolladores manejen adecuadamente las dependencias de versiones de grano fino).
Una cosa es administrar versiones de módulos con un sistema de repositorio de compilación como Maven. Maven trabaja extremadamente bien haciendo lo que hace.
Sin embargo, es una cuestión completamente diferente lidiar con ese problema en un entorno de tiempo de ejecución del usuario final distribuido en una población de millones de usuarios.
.NET GAC no es en modo alguno una solución suficiente para este viejo problema de Windows.
Los ensamblados DLL de consumo privado continúan siendo infinitamente preferibles. Es una forma obvia de ir, ya que el espacio de disco es extremadamente barato en estos días (~ $ 100 puede por unidad de terabyte en Fry en estos días). No hay nada que ganar compartiendo asambleas con otros productos, y sin embargo la reputación de la compañía se pierde cuando las cosas van hacia el sur para el usuario pobre.
Bueno, trabajé en Microsoft durante media década donde traté con problemas de DLL/COM/DCOM en cada proyecto con el que me involucré. Y luego trabajé en el proyecto .NET cuando se desarrolló por primera vez, donde curar el problema del DLL/COM a través de montajes privados era un resultado explícitamente deseado – RogerV
En realidad, NO es necesario registrar un dll en .NET en la máquina de destino.
Si hace referencia a .dll en su aplicación, haga clic en el archivo .dll al que se hace referencia en las referencias de su proyecto, mire las propiedades y establezca Aislado en VERDADERO.
Esto ahora incluirá automáticamente este .dll en su proyecto y su aplicación utilizará la copia del archivo .dll incluido en su proyecto sin necesidad de registrarlo en el sistema de destino.
Para ver un ejemplo práctico de esta mirada aquí: tendrá que ser registrado en el sistema en el que construir su solicitud para que esto funcione correctamente
http://code.msdn.microsoft.com/SEHE
El .dll en cuestión. Sin embargo, una vez que construya su proyecto, no será necesario registrar el .dll en cuestión en ningún sistema que implemente su aplicación o programa.
Una ventaja adicional de usar este método es que, incluso si en el futuro, otro .dll se registra con el mismo nombre en el sistema de destino en cuestión, su proyecto continuará utilizando el .dll con el que implementó. Esto es muy útil cuando a.dll tiene muchas versiones y desea mantener cierta estabilidad, como usar el que ha probado, pero todas las demás aplicaciones usarán el .dll registrado a menos que también utilicen el método isolated = true.
El ejemplo anterior es uno de esos casos, hay muchas versiones de Skype4COM que es un .dll API de Skype y puede cambiar a menudo.
Este método permite que el ejemplo anterior use el API .dll con el que se probó el proyecto, cada vez que un usuario instala una nueva versión de Skype, es posible que se instale una versión modificada de este .dll.
Además, hay algunos clientes de Skype que no instalan este .dll, la versión comercial del cliente de Skype, por ejemplo, es más pequeña y no incluye este .dll, por lo que en este caso, el proyecto no falla en ese .dll falta y no está registrado porque está incluido en el proyecto como aislado = verdadero.
Esto es incorrecto. Si el ensamblaje tiene un nombre fuerte, primero revisará el GAC. Si no tiene un nombre seguro, entonces el sistema comprobará primero el GAC, luego siga el siguiente procedimiento para localizar el ensamblado http://msdn.microsoft.com/en-us/library/15hyw9x3.aspx – Spence
arg, si no tiene un nombre fuerte, el sistema NO verificará el GAC, excpuse el error tipográfico. – Spence
¿Esto se aplicaría a algo así como "Office.dll" y "Microsoft.Office.Interop.Outlook.dll" también? Son objetos 'COM', pero me parece que no es necesario que los registre y ayudan a mi aplicación en los sistemas de destino (sin ellos, la aplicación falla en XP (aunque no en Win7)). –