2008-10-07 10 views

Respuesta

10

Creo que Andy dio con esta respuesta, pero no estoy seguro de que el aspecto relacionado con las reglas de carga de CLR sea el correcto.

El ensamblado .NET que contiene la clase que actúa como envoltorio para GZipStream estaría expuesto a COM y registrado como cualquier otra biblioteca y clase de proyecto COM. En este sentido, VBA encontraría la ubicación del ensamblado .NET expuesto a COM a través del registro. Puede ser inteligente colocar el ensamblado en el GAC, para que no pueda moverse (ya que mover el ensamblaje invalidaría la información de registro), pero siempre que el registro apunte al lugar correcto, debería estar bien.

tutorial es un buen principiante en el tema es here

Espero que esto ayude ...

+0

yo sólo recordaba leído en alguna parte que con el fin de utilizar un objeto .NET desde COM, el montaje sea necesario para estar en el mismo directorio que el exe, o en el GAC. Ha pasado un tiempo, así que podría estar muy equivocado. – Andy

+0

¡Esto también me parece correcto! (lol) Pero creo que lo que escribiste es cómo el CLR busca ensamblajes .NET y probablemente también se aplica para el COM sin registro. Este caso está buscando un ensamblado .NET, pero en lo que respecta al llamador COM, ni siquiera conocen .NET. –

+0

+ 1 ... Ahora puedes comentar ... –

2

VBA puede hacer uso de cualquier objeto .NET que están expuestos a COM. No sé si GZipStream es o no, pero supongo que sería más fácil para usted crear un objeto .NET separado que es un envoltorio alrededor de la funcionalidad de GZipStream que desea utilizar. A continuación, puede exponer su objeto a COM, y luego VBA debe hacer uso de él.

Tenga en cuenta que el conjunto que contiene su objeto COM (y su biblioteca de tipos también, creo, aunque no estoy seguro) deben estar en el mismo directorio que el ejecutable principal (winword.exe, o lo que sea)) o en el GAC. Esto se debe a las reglas de carga de CLR para ensamblajes.

Cuestiones relacionadas