¿Es posible hacer referencia a una DLL COM en un proyecto administrado por ruta en lugar de por GUID?

Question

Tengo un proyecto administrado (asp.net, en realidad) que hace referencia a una DLL COM. En este momento, la referencia en el .csproj se ve así:

<COMReference Include="thenameinquestion"> 
    <Guid>{someguidhere}</Guid> 
    <VersionMajor>1</VersionMajor> 
    <VersionMinor>0</VersionMinor> 
    <Lcid>0</Lcid> 
    <WrapperTool>tlbimp</WrapperTool> 
</COMReference> 

Esto funciona, pero tiene la desafortunada consecuencia de que la DLL necesita ser registrado en la máquina de construcción, lo que significa (entre otras cosas) es inconveniente para compilar varias versiones del proyecto que usan versiones diferentes de la DLL en la misma máquina de compilación.

MSDN muestra la tarea ResolveComReference que parece que hace lo correcto, pero mi google-search-fu no ha sido lo suficientemente bueno para llegar a un ejemplo real de su uso. ¿Es posible hacer lo que quiero? ¿Estoy en el camino correcto?

Answer 1

Este artículo muestra cómo realizar la activación sin registro de los componentes COM. Quizás ayude: http://msdn.microsoft.com/en-us/library/ms973913.aspx

Answer 2

Como John Fisher señaló que ya está buscando Registration-Free COM Interop. Ya hay muchas preguntas con respecto a esto, busque la 'tag at hand' regfreecom y la etiqueta estrechamente relacionada sxs también.

Usted verá fácilmente, sin embargo, que esto puede ser un escenario difícil, en particular:

• Parece que hay un error que afecta confirmed esto en Windows XP, consulte here para más detalles. Sin embargo, ya hay disponible una revisión, que podría ser suficiente siempre que se oriente solo a un entorno controlado, p. tu máquina de construir
• Dado que su objetivo es ASP.NET, debe tener en cuenta que, a diferencia de, por ejemplo, una aplicación de escritorio implica que no tiene el control del proceso de alojamiento, que puede variar según la plataforma de implementación. Esto significa que no será fácil suministrar el manifiesto de aplicación requerido para controlar el enlace en tiempo de ejecución y la activación de su componente COM dentro del host (consulte el siguiente punto para obtener una alternativa potencial).
• ASP.NET 2.0 parece complicar las cosas aún más al dejar de lado la funcionalidad para componentes no administrados. No he encontrado una fuente oficial para esto, pero el autor de Isolating ASP .Net 2.0 Applications parece estar al tanto; él está ofreciendo al menos una solución, que parece complicada y potencialmente frágil.

Resumiendo esto, me gustaría hacer hincapié en que 'Registration-Free COM Interop' puede ser muy útil y facilitar muchos escenarios. Aún así, puede que las cosas no sean más fáciles ni siquiera posibles para su escenario y entorno en particular (ASP.NET alojado).

¡Buena suerte, por favor, háganos saber si lo logró!

Answer 3

Parece que no es posible: Visual Studio solo verá el GUID mencionado en la referencia, no le importa la ruta que se insinúa allí.

Tuvimos un problema similar con nuestro servidor de compilación diario: el cliente COM no compilaría a menos que el servidor COM esté registrado. Acabamos de agregar el registro/anulación de registro a la secuencia de compilación: registra (regsv32) el componente, luego VS se ejecuta desde la línea de comando e inmediatamente después de completarse VS anula el registro del componente (regsvr32 -u). Funciona sin problemas.

Answer 4

Cuando hace referencia a una DLL COM, Visual Studio genera automáticamente un conjunto de interoperabilidad para ella.Encuentro que tomar control manual de este proceso es una gran manera de desacoplar las compilaciones COM y .NET.

1. Crea tu propio ensamblado de interoperabilidad para la DLL COM usando tlbimp.exe. Ver MSDN para los parámetros de la línea de comando.
2. Haga referencia a su ensamblado de interoperabilidad en el proyecto .NET en lugar de COM DLL.

Una vez que hace esto, ya no tiene que tener la DLL COM registrada en la máquina cuando crea la solución .NET, solo se requiere su ensamblado de interoperabilidad.

El conjunto de interoperabilidad puede permanecer en una carpeta sin cambios para siempre hasta el momento en que (a) la DLL COM interrumpa la compatibilidad binaria o (b) se realice un cambio en la interfaz COM que realmente utiliza el código .NET.

Si tiene versiones diferentes de COM DLL que son todas compatibles con binarios, compile el conjunto de interoperabilidad con la versión más antigua que contenga las interfaces que requiere el código .NET. Entonces no tendrá que actualizar el ensamblado de interoperabilidad para diferentes versiones.

Además, no necesita incluir la DLL COM en su instalador si está en condiciones de suponer que la DLL COM ya estará instalada en la máquina de destino.