2013-10-09 6 views
0

Для моего проекта было обновлено код UI-стороны. Он был преобразован с VB6 на VB.NET. Из-за этого я хотел бы изменить, как код UI-интерфейса взаимодействует с моим кодом на стороне процессора.Выводить собственный класс C++ для VB.NET

В настоящее время на стороне двигателя код COM объект, который производится следующим образом:

_engine = CreateObject("MyEngine") 

Я хотел бы изменить это так, что он будет загружен двигатель в качестве сборки .NET. Что-то вроде:

Dim asm As Reflection.Assembly = Reflection.Assembly.LoadFrom("MyEngine.dll") 
_engine = asm.CreateInstance("TestEngine") 

Итак, чтобы достичь этого, я изменил родной C++ CEngine класс будет скомпилирован с /clr. После выполнения некоторых настроек проекта он успешно скомпилировался.

Следующая часть - моя проблема (у меня мало опыта в этом). Мне нужно, чтобы он был «видимым» в .NET. Поэтому, читая онлайн, кажется, что лучшим решением является создание управляемого класса для «обертывания» вокруг моего родного класса.

Вот некоторый код для моей маленькой обертке ... ничего слишком сложно:

Wrapper.h

public ref class TestEngine 
{ 
public: 
    TestEngine(void); 
    virtual ~TestEngine(void); 
protected: 
    !TestEngine(void); 
private: 
    CEngine *_engine; // native (COM) c++ object pointer 
}; 

Wrapper.cpp

#include "Wrapper.h" 
TestEngine::TestEngine(void) 
{ 
    _engine = new CEngine(); 
} 

TestEngine::~TestEngine(void) 
{ 
    if (_engine) 
    { 
     delete _engine; 
     _engine = NULL; 
    } 
} 

TestEngine::!TestEngine(void) 
{ 
    if (_engine) 
    { 
     delete _engine; 
     _engine = NULL; 
    } 
} 

Так что здесь ошибка, я не могу создать экземпляр CEngine, потому что его методы COM (QueryInterface, AddRef и Release) являются абстрактными. Итак, мой вопрос: должен ли я получить этот класс и создать экземпляр производного класса? Я даже иду по правильному пути здесь? Моя главная цель - избавиться от неуправляемой/управляемой границы между моим кодом интерфейса и кодом двигателя, если это возможно. Таким образом, исключая использование COM внутри, а вместо этого, загружая сборки .NET.

ответ

1

У меня относительно мало опыта работы с COM-взаимодействием, но по моему опыту вы можете просто добавить ссылку на COM-DLL в свой проект и автоматически запускать tlbimp.exe, который создает сборку COM-взаимодействия (управляемую сборку, которая имеет исполняемые среды для всех классов COM).

Проверить эту страницу из: http://msdn.microsoft.com/en-us/library/697w37zd.aspx

Я использовал этот подход в нескольких проектах.

+0

Спасибо - на самом деле, я думаю, что проект использует некоторые межсетевые экраны, чтобы действовать как интерфейс к методам движка. Но в любом случае мой босс хочет, чтобы эти межсетевые экраны ушли и загрузили сборки. По-видимому, они вызывают неудачу в тестировании блока проекта ... – ryrich

Смежные вопросы