.NET COM Interop на Windows 7 64Bit дает мне головную боль

Question

.NET COM interop пока что работает очень хорошо. Поскольку я обновился до Windows 7, я больше не использую мои COM-объекты .NET.

Мой COM объект так же легко, как:

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 
    { 

    } 
} 

 

сборка помечается ComVisible, а также.

зарегистрировать сборку с помощью

regasm /codebase /tlb "path"

регистры успешно (режим администратора). Я пробовал regasm 32 и 64bit. Как раз, когда я получаю ошибку

«ActiveX компонент наклоняю создать объект Crap.MyClass» с помощью этого VBScript:

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

fuslogvw не дает мне никаких намеков либо. Этот COM-объект отлично работает на моей 32-битной машине Vista.

Я не понимаю, почему я не смог найти решение этой проблемы. Я действительно единственный человек, который когда-либо попадал в эту проблему?

Глядя на OleView Я вижу, что мой объект зарегистрирован успешно. Я также могу создавать другие COM-объекты, но он не работает только с моими собственными.

Спасибо, Kevin

Answer 1

Я не C# человек, но вот пример, который я преобразовал из VB.net. Заметьте, я должен был убедиться, что у меня есть одно пространство имен на уровне проекта, а затем этот класс в проектах VB. Я понимаю, что это отличается от проектов 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() 
    { 
    } 
} 

Если меня беспокоит COM, я всегда проверяю его в реестре, чтобы убедиться, что были созданы соответствующие записи. Я обнаружил, что проблемы с установкой версий и MSI вызывают проблемы, прежде всего удаляя (не очищает реестр) или повторно устанавливают, а MSI с. NET COM-объектами, которые перезаписывают существующую запись COM, вызывает всевозможные неприятности.

Как правило, вы обнаружите, что вам нужно быть осторожным относительно x64 vs x32 build .net DLL.Например, вам может потребоваться явно указать C: \ Windows \ SysWow64 \ или C: \ Windows \ System32 \ выпуски движка VBS.

Наконец, если вы используете VBS на веб-сайте ASP на сервере x64 с компонентом COM. X32, то вам необходимо обеспечить расширенную опцию пула приложений IIS 7. Правильно установлено 32-битное приложение True/False.

Answer 2

Спасибо! Не знаю, было ли 2 реестра, о которых я должен позаботиться .. было время переключиться на Win7 64 бит, я думаю :)

Спасибо.

Для всех остальных, что работает в одной и той же проблемой: Wscript (клиент, который выполняет VBS файлы обычно) выполняется в 64-разрядном режиме => Regasm 64-битной будет использоваться

Другие общие клиенты, такие как Excel выполняются в Должен использоваться 32-битный режим => RegAsm 32bit.

Visual Studio выполнен в 32bit => Register for COM interop регистрирует только COM-объект в 32-битном реестре.

Единственное, что теперь я должен выяснить, как убедиться, что программа установки VS регистрирует обе версии