C# usar una DLL legado simplemente sin registro (regsvr32)

Question

Situación
Tengo un sistema de construcción que se ejecuta muchas construcciones para muchos proyectos. Para evitar que una construcción afecte a otra, bloqueamos al usuario de compilación solo a su área de trabajo. Las compilaciones se ejecutan como usuarios sin privilegios que solo tienen capacidad de escritura en el área de trabajo.

Desafío
Durante nuestra nueva construcción que tenemos que utilizar un legado 3rdparty DLL que expone su interfaz a través de COM. El equipo de desarrollo quiere registrar la compilación (regsrv32.exe) pero nuestro régimen de seguridad de compilación bloquea esta actividad. Si relajamos el régimen, la DLL de terceros afectará a otras compilaciones y si tengo dos compilaciones que necesitan dos versiones diferentes, es posible que tenga una compilación de compilación incorrecta con respecto a la versión incorrecta (una posibilidad muy real).

Pregunta
¿Hay otras opciones además de registro para manejar archivos DLL de legado que exponen su interfaz a través de COM?

Gracias por la ayuda

Peter

Answer 1

Hay un tutorial en COM sin registro aquí:

http://msdn.microsoft.com/en-us/library/ms973913.aspx

Y insoportable detalle aquí: http://msdn.microsoft.com/en-us/library/aa376414 (la raíz de ese documento es en realidad aquí: http://msdn.microsoft.com/en-us/library/dd408052)

Además, para En general, debe poder usar Tlbimp o tlbexp para crear un archivo TLB que pueda usar para compilar, suponiendo que el punto de registro es solo para poder compilar correctamente y no ejecutar pruebas específicas. s.

Answer 2

• Si tiene acceso a la tercera parte .DLL de que puede GAC ellos, y hacer referencia a ellos en su proyecto
• se puede añadir una usando a su .cs encabezado de archivo, así como agregar la referencia al proyecto haciendo clic derecho en referencia -> agregar referencia ...
• también puede hacer el paso anterior así como establecer la copia local = true en las propiedades para ese .dll .. Espero que esto te de algunas ideas ... tener en cuenta que son ensamblados .NET Managed código por lo que hay varias maneras de consumir aquellos tercera parte utilizando otros métodos de .DLL en C# como LoadFromAssembly ect ..

Answer 3

herramientas de instalación tales como Installshield pueden extraer las interfaces COM de la DLL y agréguelos al registro. También puede usar el proceso de autorregistro de la DLL (que creo que es lo que hace regsvr), pero esto no es un Microsoft installer best practice.

Answer 4

Gracias por la ayuda. Cambiamos de vinculación temprana a vinculación tardía porque realmente nunca necesitábamos la DLL en tiempo de compilación. Esto impulsó el requisito de registro del servidor de compilación al servidor de prueba de integración (donde ejecutamos el instalador que maneja el registro). Tratamos de mantener el sistema de compilación prístino y tener sistemas de integración fáciles de reiniciar.

Gracias de nuevo Peter

Answer 5

Para mi primera respuesta a una pregunta similar, véase: TFS Build server and COM references - does this work?

Una buena manera de compilar el código .NET que hace referencia a los componentes COM sin los componentes COM están registrados en el servidor de compilación es para utilizar el elemento de referencia COMFileReference en los archivos de proyecto/compilación en lugar de COMReference. Un elemento COMFileReference se ve así:

<ItemGroup> 
    <COMFileReference Include="MyComLibrary.dll"> 
    <EmbedInteropTypes>True</EmbedInteropTypes> 
    </COMFileReference> 
</ItemGroup> 

Desde Visual Studio no ofrece soporte de diseñador para COMFileReference, debe modificar el proyecto/construcción fichero a mano.

Durante una compilación, MSBuild extrae la información de la biblioteca de tipos de la DLL COM y crea un conjunto de interoperabilidad que puede ser independiente o incrustado en el ensamblado .NET de la llamada.

Cada elemento COMFileReference también puede tener un atributo WrapperTool pero el valor predeterminado parece funcionar bien para mí. El atributo EmbedInteropTypes no está documentado como aplicable al COMFileReference, pero parece que funciona según lo previsto.

Ver http://msdn.microsoft.com/en-us/library/bb629388.aspx para un poco más de detalle. Este elemento MSBuild ha estado disponible desde .NET 3.5.

Es una lástima que nadie parezca saber nada sobre esta técnica, que para mí parece más simple que las alternativas. En realidad, no es sorprendente ya que solo pude encontrar la referencia anterior en línea. Yo mismo descubrí esta técnica al profundizar en el archivo Microsoft.Common.targets de MSBuild.