.NET de interoperabilidad COM en Windows 7 64 bits me da un dolor de cabeza

Question

.NET de interoperabilidad COM hasta ahora siempre ha estado trabajando bastante bien. Desde que actualicé a Windows 7, ya no logro que mis objetos COM de .NET funcionen.

Mi objeto COM es tan fácil como:

namespace Crap 
{ 
    [ComVisible(true)] 
    [Guid("2134685b-6e22-49ef-a046-74e187ed0d21")] 
    [ClassInterface(ClassInterfaceType.None)] 
    public class MyClass : IMyClass 
    { 

     public MyClass() 
     {} 

     public void Test() 
     { 
      MessageBox.Show("Finally got in here."); 
     } 

    } 
} 



namespace Crap 
{ 
    [Guid("1234685b-6e22-49ef-a046-74e187ed0d21")] 
    public interface IMyClass 
    { 

    } 
} 

 

montaje está marcada ComVisible también.

que registrar el ensamblado utilizando

regasm /codebase /tlb "path"

registros con éxito (modo de administrador). Probé Regasm 32 y 64 bits. Tanto el tiempo me sale el error

"componente ActiveX no puedo crear Crap.MyClass objeto" usando este VBScript:

dim objReg 
Set objReg = CreateObject("Crap.MyClass") 
MsgBox typename(objReg) 
 

fuslogvw- no me da ninguna pista tampoco. Ese objeto COM funciona perfectamente en mi máquina Vista 32 Bit.

No entiendo por qué no he sido capaz de google una solución para ese problema .. soy realmente la única persona que alguna vez se metió en ese problema?

En cuanto a Oleview veo mi objeto se registró correctamente. También puedo crear otros objetos COM ... solo que no funciona con los míos.

Gracias, Kevin

Answer 1

No soy una persona # C, pero en este caso es un ejemplo que me convertido de VB.net. Tenga en cuenta que tuve que asegurarme de tener un solo espacio de nombres en el nivel del proyecto, luego esta clase en proyectos de VB. Entiendo que eso es diferente en los proyectos de C#.

[ComClass(MyClass.ClassId, MyClass.InterfaceId, MyClass.EventsId)] 
public class MyClass { 

    // These GUIDs provide the COM identity for this class 
    // and its COM interfaces. If you change them, existing 
    // clients will no longer be able to access the class. 
    public const string ClassId = "f58411e1-1689-4bf3-a0e1-b49f479e28ba"; 
    public const string InterfaceId = "f4a575c6-62d2-44eb-af0f-f5b2bb65ad51"; 
    public const string EventsId = "ad56e4f9-3512-4233-aae4-7d1c2457c08f"; 

    // A creatable COM class must have a Public Sub New() 
    // with no parameters, otherwise, the class will not be 
    // registered in the COM registry and cannot be created 
    // via CreateObject. 
    public SalePayStatus() : base() 
    { 
    } 
} 

Si me preocupa el COM, siempre compruebo primero el registro para garantizar que se hayan creado las entradas correspondientes. Descubrí que las versiones y la instalación de MSI causan problemas, especialmente la desinstalación (no limpia el registro) o la reinstalación, y MSI con los objetos .NET COM que sobrescribe una entrada COM existente causa todo tipo de problemas.

por lo general encontrará que usted tiene que tener cuidado sobre x64 vs x32 construir DLL .net.Por ejemplo, puede que tenga que hacer referencia explícita a C: \ Windows \ SysWow64 \ o C: \ Windows \ System32 \ editions del motor VBS.

Por último, si usa VBS en un sitio web ASP en un servidor x64 con un componente COM COM NETO x32, deberá asegurarse de que la opción avanzada del conjunto de aplicaciones IIS 7 sea correcta o falsa.

Answer 2

Gracias! No sabía que eran 2 registros tengo que cuidar de .. era hora de cambiar a Win7 64 bits supongo :)

Gracias.

Para todos los demás que se encuentra con el mismo problema: wscript (el cliente que ejecuta vbs archivos por lo general) se ejecuta en modo de 64 bits => RegAsm de 64 bits es para ser utilizado

Otros clientes comunes como Excel se ejecutan en Modo de 32 bits => RegAsm 32bit es para ser utilizado.

Visual Studio se ejecuta en 32 bits => Registrar para interoperabilidad COM sólo registra el objeto COM en el registro de 32 bits.

Lo único que ahora tengo que averiguar es cómo asegurarse de que la instalación VS registra ambas versiones