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