2011-05-11 10 views
8

Tenemos un viejo C/C++ .dll que está COM registrado. Nuestros clientes tienen clientes nativos y .NET que usan este .dll..NET Client crasch cuando reemplaza COM .dll registrado por uno nuevo en la misma versión de .NET como cliente

Hemos creado un nuevo .NET .dll para reemplazar el antiguo, es decir, su interfaz COM es idéntica. Nos gustaría reemplazar el viejo .dll sin que nuestro cliente necesite recompilar o hacer algo a sus clientes.

Para clientes nativos, funciona bien simplemente anular el registro del antiguo .dll y registrar el nuevo (con regasm). También funciona para algunos clientes .NET. Sin embargo, en esos casos, tanto el cliente como el nuevo .dll se compilan con la misma versión .NET arroja la excepción a continuación.

En otras palabras, esto funciona:

.dll is .NET 3.5 -> client is .NET 4.0 
.dll is .NET 4.0 -> client is .NET 3.5 
.dll is any .NET -> Client is native 

Esto arroja la excepcion a continuación:

.dll is .NET 4.0 -> client is .NET 4.0 
.dll is .NET 3.5 -> client is .NET 3.5 

[A] BARAPIXLib.barcom5 no pueden ser echados a [B] BARAPIXLib.barcom5.

El tipo A se origina de 'BARAPIXLib, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' en el contexto 'LoadFrom' en la ubicación C: \ arkiv \ S_BTW \ BTW \ BARAPIXWebService \ Barapix \ bin \ BARAPIXLib. dll '.

El tipo B se origina de 'BartrackTest, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' en el contexto 'Default' en la ubicación 'C: \ arkiv \ Bartrack \ BartrackTest \ x86 \ Src \ BartrackTest \ bin \ x86 \ Release \ BartrackTest.exe'. "}

sería apreciada cualquier idea.

+0

¿Alguna posibilidad de que podamos ver la declaración de la referencia del método DLL así como algún código de llamada? – pickypg

+0

¿Quiere decir cómo los clientes llaman a nuestro .dll? Eso es desconocido para nosotros, pero es probable que hayan hecho "Agregar referencia" en Visual Studio. Queremos reemplazar nuestro antiguo C/C++ COM .dll con un nuevo .NET sin que los clientes necesiten ser recompilados ni nada. Si esto es posible. – Poppert

Respuesta

1

Intenta anular el registro de cualquier versión anterior y comprobar que la DLL está en la misma carpeta que el ejecutable. también intente buscar en donde está cargando el dll. Creo que lo está cargando manualmente así que mire la dirección que está haciendo referencia al dll incorrecto.

+0

¡Gracias por su respuesta! Desregistramos el viejo C/C++ .dll, reemplazamos el archivo con el nuevo .NET uno (usando el mismo nombre de archivo y en el mismo directorio) y lo registramos usando regasm. Pero el cliente aún no funciona (sin tener que volver a compilar, etc.). Básicamente dice: No se puede enviar SomeTypeA a SomeTypeAClass ("Class" se agrega de alguna manera al nombre de tipo). – Poppert

1

Esto podría deberse a que en el caso en que está utilizando la misma versión de .NET Framework, la instancia devuelta al cliente ya no es un contenedor COM sino un objeto .Net puro, por lo que cuando intente convertirlo en un La interfaz COM falla. Hay una pregunta similar here. La solución implica el uso de Primary Interop Assembly.

+0

¡Gracias por su respuesta! Nuestros clientes ya han hecho "Agregar referencia" a nuestro anterior C/C++ COM .dll, por lo que existe un "Interop.blablabla.dll" en el directorio de cliente que utiliza el cliente .exe. ¿Podemos forzar a los clientes de nuestros clientes a utilizar un nuevo conjunto primario de interoperabilidad en lugar del que ya están utilizando (sin tener que recompilar, etc., a sus clientes)? – Poppert

+0

@Poppert Me da miedo que esto no sea posible. Por lo que sé, la PIA probablemente tendrá diferentes nombres de tipos.De cualquier manera, puede ser una buena idea publicar una nueva pregunta sobre SO sobre este tema específicamente, puede obtener algunas soluciones creativas. – yms

Cuestiones relacionadas