I'm working on my first COM project that is importing a c# DLL with a C# COM Wrapper class into a C++ native code application. Our application is based on the CSRegFreeCOMServer VS2008 sample project from Microsoft's All-In-One Framework. Our system is using - VS2008, .Net3.5, boost 1.4.2 and Qt 4.6.2.
This application has been running fine on our 32bit XP dev boxes. However, when we load the system onto our Windows 7-64bit system. We cannot get the com objects to initialize. We keep getting error 0x80040154 (which I cannot seem to determine what it means).
Our header file is -
#ifndef ControlComInterface_h__
#define ControlComInterface_h__
#include <string>
#include <ole2.h> // OLE2 Definitions
// Importing mscorlib.tlb is necessary for .NET components
// see:
// http://msdn.microsoft.com/en-us/library/s5628ssw.aspx
#import "mscorlib.tlb" raw_interfaces_only \
high_property_prefixes("_get","_put","_putref") \
rename("ReportEvent", "InteropServices_ReportEvent")
using namespace mscorlib;
// import the COM Declarations exported com the CSRegFreeCOMServer
#import "..\CSRegFreeCOMServer\bin\Release\CSRegFreeCOMServer.tlb" no_namespace named_guids
using namespace std;
class ControlComInterface
{
public:
ControlComInterface(void);
~ControlComInterface(void);
IFieldsPtr spFields;
IPchFilePtr spPchFileWrapper;
bool CreateInterfaceObjects(string &errorMsg);
};
#endif // ControlComInterface_h__
The simplified class code is
#include "ControlComInterface.h"
#include <boost/lexical_cast.hpp>
ControlComInterface::ControlComInterface(void)
{ }
ControlComInterface::~ControlComInterface(void)
{ }
bool ControlComInterface::CreateInterfaceObjects( string &errorMsg )
{
HRESULT hr = S_OK;
hr = ::CoInitialize(NULL);
if (FAILED(hr))
{
errorMsg = "CoInitialize failed w/err: ";
errorMsg.append(boost::lexical_cast<string>(hr));
return false;
}
errorMsg = "";
hr = spFields.CreateInstance(__uuidof(Fields));
if (FAILED(hr))
{
errorMsg = "IFields::CreateInstance failed w/err: ";
errorMsg.append(boost::lexical_cast<string>(hr));
return false;
}
return true;
}
The code is failing with a error code of 0x80040154 on the call to spFields.CreateInstance(...), which just creates an instance of the class in the com object using a default constructor.
Suggestions?
0x80040154 is REGDB_E_CLASSNOTREG. That is, class not registered.
The COM couldn't find (in the registry) the class factory with CLSID = __uuidof(Fields).
Related
On Win 7 SP1 with Convenience Update (latest Win 7 that was shipped), my C++ code using CUIAutomation from Windows Automation 3.0 cannot get the TextPattern from the RichEdit control in the built-in WordPad application. However, the equivalent C# code using UIAutomationClient and UIAutomationTypes can.
Better success on Win 10: both the C++ code and the C# code successfully get the TextPattern.
My main project has compatibility issues with another C# UIA application, which went away when I use the C++ code on Win 10. So I really want to use the C++ code on Win 7 also. Does anyone know why the C++ code fails and how to fix it? I am quite surprised that getting a simple TextPattern out of the built-in RichEdit control does not work reliably!
Here is the C# code (much easier to read!), followed by the C++ code:
using System;
using System.Threading;
using System.Windows.Automation;
namespace UIAutomationNET
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Getting element at cursor in 3 seconds...");
Thread.Sleep(3000);
var element = AutomationElement.FocusedElement;
if (element != null)
{
var textPatternElement = element.FindFirst(
TreeScope.Subtree,
new PropertyCondition(AutomationElement.IsTextPatternAvailableProperty, true));
if (textPatternElement == null)
Console.WriteLine("No element supporting TextPattern found.");
else
Console.WriteLine("TextPattern is supported! :-)");
}
}
}
}
The following C++ code is based on this MSDN Code Gallery sample:
#include <windows.h>
#include <ole2.h>
#include <uiautomation.h>
#include <strsafe.h>
IUIAutomation *_automation;
int _cdecl wmain(_In_ int argc, _In_reads_(argc) WCHAR* argv[])
{
UNREFERENCED_PARAMETER(argc);
UNREFERENCED_PARAMETER(argv);
// Initialize COM before using UI Automation
HRESULT hr = CoInitialize(NULL);
if (FAILED(hr))
{
wprintf(L"CoInitialize failed, HR:0x%08x\n", hr);
}
else
{
// Use CUIAutomation instead of CUIAutomation8 on Win 7
hr = CoCreateInstance(__uuidof(CUIAutomation), NULL,
CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&_automation));
if (FAILED(hr))
{
wprintf(L"Failed to create a CUIAutomation, HR: 0x%08x\n", hr);
}
else
{
IUIAutomationElement *element = NULL;
wprintf( L"Getting element at cursor in 3 seconds...\n" );
Sleep(3000);
POINT pt;
GetCursorPos(&pt);
hr = _automation->ElementFromPoint(pt, &element);
if (FAILED(hr))
{
wprintf( L"Failed to ElementFromPoint, HR: 0x%08x\n\n", hr );
}
if (SUCCEEDED(hr) && element != NULL)
{
IUIAutomationElement *textElement = NULL;
// Create a condition that will be true for anything that supports Text Pattern
// Use UIA_IsTextPatternAvailablePropertyId instead of UIA_IsTextPattern2AvailablePropertyId on Win 7
IUIAutomationCondition* textPatternCondition;
VARIANT trueVar;
trueVar.vt = VT_BOOL;
trueVar.boolVal = VARIANT_TRUE;
hr = _automation->CreatePropertyCondition(UIA_IsTextPatternAvailablePropertyId, trueVar, &textPatternCondition);
if (FAILED(hr))
{
wprintf(L"Failed to CreatePropertyCondition, HR: 0x%08x\n", hr);
}
else
{
// Actually do the search
hr = element->FindFirst(TreeScope_Subtree, textPatternCondition, &textElement);
if (FAILED(hr))
{
wprintf(L"FindFirst failed, HR: 0x%08x\n", hr);
}
else if (textElement == NULL)
{
wprintf(L"No element supporting TextPattern found.\n");
hr = E_FAIL;
}
else
{
wprintf(L"TextPattern is supported! :-)\n");
}
textPatternCondition->Release();
}
}
_automation->Release();
}
CoUninitialize();
}
return 0;
}
If I remember correctly, the Win7 native UI Automation provider did not support TextPattern, while the managed UI Automation provider did.
The native UI Automation provider didn't add TextPattern support until Windows 8.
For a long time I have a problem with a project that I have to implement in mine, I'll explain it to you.
My goal is to call a C ++ class from a C # application (Project 1), the problem is that the C ++ project (Project 3) is not compatible with CLR.
What I have done so far has been created an intermediate project also in unmanaged C ++ (Project 2) to be compatible with the project 3.
Project 2 consists of a very simple method that initializes a class from project 3 and uses this object for different operations.
I'm working in Visual Studio and it does not give me an error when compiling, but at run time I get the following error:
Unable to load the DLL file 'PROJECT-ROUTE \ Project2.dll': The specified procedure could not be found. (Exception from HRESULT: 0x8007007F)
in project1.process ()
The thing is that the previous error comes out only when within the project2 method I initialize the class from project 3, if I comment the initialization line then it goes well, I can not understand why between 2 C ++ projects of the same type gives me this type of problems.
Can somebody help me?
thank you
C# Code (Project 1)
private const string DllFilePath = #"PATH_TO_DLL\Proyect2.dll";
[DllImport(DllFilePath, CallingConvention = CallingConvention.Cdecl, EntryPoint = "process")]
public extern static void process();
[HandleProcessCorruptedStateExceptions]
public static string Prox(string a, string b)
{
string str = "OK";
try
{
process();
}
catch (System.AccessViolationException exception)
{
return exception.Message + " " + exception.StackTrace;
}
catch (Exception exception)
{
return exception.Message + " " + exception.StackTrace + " ";
}
return str;
}
}
Middle proyect Unamanged C++ Code (Project 2)
Project2.h
#include <stdexcept>
#include "Project3.h"
using namespace std;
namespace FinalProcess
{
extern "C" { __declspec(dllexport) void __cdecl process(); }
}
Project2.cpp
#include "Project2.h"
#include <iostream>
#include <chrono> // To measure execution time
namespace FinalProcess
{
void process()
{
OCTA::Analyzer& ld = OCTA::Analyzer::getInstance(); // <-- Singleton
// if I comment this line then it goes well
}
}
Assuming that the information that you present here is correct (and I have my doubts because you've not copied it verbatim as can be seen from the DLL name of Proyect2.dll) then the error cannot be that the function process is not found. In which case the error has to be in the linking to Project3.
Your Project2.dll is presumably attempting to link to Project3.dll and to a function that is not exported from Project3.dll. That would explain the behaviour that you report. This would happen typically if the Project3.lib file that you linked when building Project2.dll did not match the Project3.dll file found by the executable at runtime.
Make sure that the version of Project3.dll that is being loaded is up to date and matches the .h and .lib files you used to build Project2.dll.
Rather than give an absolute path of the DLL in your C# code, you just the file name of the DLL. Place both DLLs in the same directory as your C# executable.
I'm not a C++ programmer but rather a "code editor", so I hereby apologize sincerely in advance for the question in general.
For some broadcasting software I am editing a plug-in to give it interoperability between native C/++ and CLR (C#).
The host software: OBS (Open Broadcaster Software) - obsproject.com
The plug-in: CLR Host Plugin - github.com/kc5nra/CLRHostPlugin
What I want to do is exposing functions from OBS to some CLR libraries, the total list of exposible functions can be found here: https://github.com/jp9000/OBS/blob/master/OBSApi/APIInterface.h#L198
Now the plug-in is a proxy between the languages and exposes some of the functionalities named above through API.h/cpp, https://github.com/kc5nra/CLRHostPlugin/blob/master/CLRHostInterop/API.h. What I want to do is adding more functions to API.h to expose them to CLR libraries.
When I add a function in API.h, line 51, it'll give me linker errors.
The API.h change
namespace CLROBS
{
public ref class API
{
public:
void AddSettingsPane(SettingsPane^ settingsPane);
void AddImageSourceFactory(ImageSourceFactory^ imageSourceFactory);
IntPtr API::GetMainWindowHandle();
void Log(System::String^ format, ...array<System::Object^> ^arguments);
System::String^ GetPluginDataPath();
void SetChangedSettings(bool isChanged);
int GetMaxFPS();
void StartStopStream(); // Addition to the original.
};
};
The API.cpp change
#include "OBSApi.h"
#include "API.h"
#include "CLRHostApi.h"
#include "OBSUtils.h"
using namespace System::Runtime::InteropServices;
// Default code......
int API::GetMaxFPS()
{
return ::API->GetMaxFPS();
}
void API::StartStopStream()
{
OBSStartStopStream();
}
The Error
error LNK2022: metadata operation failed (80131187) : Inconsistent method declarations in duplicated types (types: CLROBS.API; methods: StartStopStream): (0x0600006c). <DIR>\CLRHostPlugin\CLRHostInterop\API.obj CLRHost.Interop
error LNK2022: metadata operation failed (80131187) : Inconsistent method declarations in duplicated types (types: CLROBS.API; methods: StartStopStream): (0x0600006c). <DIR>\CLRHostPlugin\CLRHostInterop\AbstractPlugin.obj CLRHost.Interop
error LNK2022: metadata operation failed (801311D6) : Differing number of methods in duplicated types (CLROBS.API): (0x02000008). <DIR>\CLRHostPlugin\CLRHostInterop\API.obj CLRHost.Interop
error LNK2022: metadata operation failed (801311D6) : Differing number of methods in duplicated types (CLROBS.API): (0x02000008). <DIR>\CLRHostPlugin\CLRHostInterop\AbstractPlugin.obj CLRHost.Interop
The in my eye's odd behaviour doesn't occur when using the plain code
namespace CLROBS
{
public ref class API
{
public:
void AddSettingsPane(SettingsPane^ settingsPane);
void AddImageSourceFactory(ImageSourceFactory^ imageSourceFactory);
IntPtr API::GetMainWindowHandle();
void Log(System::String^ format, ...array<System::Object^> ^arguments);
System::String^ GetPluginDataPath();
void SetChangedSettings(bool isChanged);
int GetMaxFPS();
// - commented out - void StartStopStream(); // Addition to the original.
};
};
Edit
Added API.cpp snippet
Even when I comment out OBSStartStopStream(); on API.cpp the error still exist.
/Edit
Please assist.
Regards,
MusicDemon
I'd like to run my WPF application from a python script, however am having difficulty.
To achieve this I have converted the WPF application to a COM library as follows:
namespace MyWpfApp
{
[Guid("F75D3377-D677-41BF-B3D5-C677C442228F")]
public interface IMyWpfAppInterface
{
void ShowCOMDialog();
void ClickButton1();
void ClickButton2();
}
[ClassInterface(ClassInterfaceType.None)]
[Guid("D936A84B-8B1C-4D62-B090-C06E3EB5EEE9")]
public class MyWpfClass : IMyWpfAppInterface
{
private static Thread m_runDlgThread;
private static MainWindow m_mainWindow = null;
private static Application m_app = null;
public MyWpfClass() { }
public void ShowCOMDialog()
{
m_msgHelper = new MessageHelper();
m_runDlgThread = new Thread(runDlg);
m_runDlgThread.SetApartmentState(ApartmentState.STA);
m_runDlgThread.Start();
}
public void ClickButton1(){// to do}
public void ClickButton2(){// to do}
private void runDlg()
{
Application m_app = new Application();
m_mainWindow = new MainWindow();
m_app.Run(m_mainWindow);
}
}
}
I have installed my assembly to the global assembly cache and registered the dll as follows
gacutil.exe" /i MyWpfApp.dll
REGASM MyWpfApp.dll /tlb:com.MyWpfApp.tlb
I have tested that I can successfully import the Typelib and run my WPF application from a win32 console application.
#include "stdafx.h"
#import "..\MyWpfApp\bin\Debug\com.MyWpfApp.tlb" named_guids raw_interfaces_only
int _tmain(int argc, _TCHAR* argv[])
{
CoInitialize(NULL); //Initialize all COM Components
// <namespace>::<InterfaceName>
MyWpfApp::IMyWpfAppInterfacePtr pDotNetCOMPtr;
// CreateInstance parameters
// e.g. CreateInstance (<namespace::CLSID_<ClassName>)
HRESULT hRes =
pDotNetCOMPtr.CreateInstance(MyWpfApp::CLSID_MyWpfClass);
if (hRes == S_OK)
{
const DWORD cTimeout_ms = 500;
HANDLE hEvent = CreateEvent(0, TRUE, FALSE, 0);
BSTR str;
pDotNetCOMPtr->ShowCOMDialog ();
bool toggle = true;
while(true)
{
DWORD dwWait = WaitForSingleObject(hEvent,cTimeout_ms);
if(toggle)
{
pDotNetCOMPtr->ClickButton1();
toggle = false;
}
else
{
pDotNetCOMPtr->ClickButton2();
toggle = true;
}
}
//call .NET COM exported function ShowDialog ()
}
CoUninitialize (); //DeInitialize all COM Components
return 0;
}
When I attempt to access the COM component from Python
import win32com.client
from win32com.client import constants as c
myWpf = win32com.client.Dispatch("MyWpfApp.MyWpfClass")
This fails, reporting
File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 114, in _GetGoodDispatchAndUserName
return (_GetGoodDispatch(IDispatch, clsctx), userName)
File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 91, in _GetGoodDispatch
IDispatch = pythoncom.CoCreateInstance(IDispatch, None, clsctx, pythoncom.IID_IDispatch)
com_error: (-2147221164, 'Class not registered', None, None)
I can see the class "MyWpfApp.MyWpfClass" int the registry and also from OLE Viewer.
I've done this kind of thing many times for a C++ based application without any problems. However this was with either an ATL project or MFC app with automation switched on. In this case I have converted WPF application to a dll and converted to COM by hand.
Could someone please advise what else I need to do to run the app from python?
Thanks in advance.
Further Edit :
I can load the typelib in python but still can't access the com class
I ran
import win32com.client
import pythoncom
myApp = pythoncom.LoadTypeLib("D:\\MyWorkSpace\\testProgs\\ATL_COM\\WPF\MyWpfApp\\MyWpfApp\\bin\\Debug\\com.MyWpfApp.tlb")
downloads_stat = None
for index in xrange(0, myApp.GetTypeInfoCount()):
type_name = myApp.GetDocumentation(index)[0]
type_iid = myApp.GetTypeInfo(index).GetTypeAttr().iid
print type_iid
print type_name
if type_name == 'MyWpfClass':
downloads_stat = win32com.client.Dispatch(type_iid)
This confirms that the classes are loaded but I can't access them because they are reported as not registered.
>>>
{B5E3A6C6-09A0-315C-BF3A-CB943389F610}
MessageHelper
{FBE23BB0-3EDC-3A65-90EB-DF84F7545D70}
COPYDATASTRUCT
{8BEE824F-F708-3052-BC21-A9EC4E1BB002}
MainWindow
{8C0044EF-91A9-3CB3-9945-1ACA076F3D7E}
NextPrimeDelegate
{F75D3377-D677-41BF-B3D5-C677C442228F}
IMyWpfAppInterface
{D936A84B-8B1C-4D62-B090-C06E3EB5EEE9}
MyWpfClass
Traceback (most recent call last):
File "D:\MyWorkSpace\testProgs\ATL_COM\WPF\MyWpfApp\MyWin32App\Python\MyPythonClient.py", line 15, in <module>
downloads_stat = win32com.client.Dispatch(type_iid)
File "C:\Python27\lib\site-packages\win32com\client\__init__.py", line 95, in Dispatch
dispatch, userName = dynamic._GetGoodDispatchAndUserName(dispatch,userName,clsctx)
File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 114, in _GetGoodDispatchAndUserName
return (_GetGoodDispatch(IDispatch, clsctx), userName)
File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 91, in _GetGoodDispatch
IDispatch = pythoncom.CoCreateInstance(IDispatch, None, clsctx, pythoncom.IID_IDispatch)
com_error: (-2147221164, 'Class not registered', None, None)
>>>
I can also confirm that there is an entry 'MyWpfApp.MyWpfClass' in the registry with the class id {D936A84B-8B1C-4D62-B090-C06E3EB5EEE9}.
Further Edit:
I tried installing Python for .Net and ran the following command
import clr;
import sys
sys.path.append('D:\\MyWorkSpace\\testProgs\\ATL_COM\\WPF\\MyWpfApp\\MyWpfApp\\bin\\Debug')
clr.AddReference("MyWpfApp.dll")
However this produced the following error
FileNotFoundException: Unable to find assembly 'MyWpfApp.dll'.
at Python.Runtime.CLRModule.AddReference(String name) in C:\Users\Barton\Documents\Visual Studio 2008\Projects\PySharp\trunk\pythonnet\src\runtime\moduleobject.cs:line 375
My knowledge of COM, Assemblies and typelibs are quite limited so I would appreciate if someone could help me understand what I need to do to access the DLL from python.
When I look at the entry in OLE/COM Object viewer, it points to the tlb file, not the dll, i.e.
Win32=D:\MyWorkSpace\testProgs\ATL_COM\WPF\MyWpfApp\MyWpfApp\bin\Debug\com.MyWpfApp.tlb
So, it is only the tlb file that is registered, not the class. When I run the LoadTypeLib class I am loading this from a path on my hard drive. I need the dll to be registered when I attempt to dispatch. Otherwise, if I can access this directly from a fixed path this would also be good but I don't know how to do this.
Again, thanks for your help.
I have a working CLI interface between C++ and C# code. The code has a C++ abstract interface like:
-------------C++ Interface---------------
namespace cppns
{
class cppInterface
{
public:
virtual bool Start(const char *pcDir) = 0;
};
}
------Implementation of abstract C++ interface in same dll---------
namespace cppns
{
class cppimp : public cppInterface
private:
gcroot<MyInternalCSharpClass^> mInternalClassAccess;
public:
cppimp::cppimp()
{
mInternalClassAccess = gcnew MyInternalCSharpClass();
}
virtual bool cppimp::Start(const char *pcDir)
{
System::AppDomain ^appDom = AppDomain::CurrentDomain::get();
System::String ^strDomainName = appDom->FriendlyName;
mInternalClassAccess->Initalize(pcDir);
}
}
---------Method to create an instance of the class in a factory--------------
cppns::cppInterface *GetImplObject()
{
return new cppns::cppimp();
}
----------Factory class .h to allow C++ to get an instance of the cppimp class------
------The C++ code knows about the abstract interface by including the header file--
------FactoryExport is __declspec(dllexport) when compiled in dll and---------------
----- __declspec(dllimport) when used as a header file in exe that uses header------
class FactoryExport ClassFactory
{
public:
static cppns::cppInterface *CreateImpl();
};
----------Factory class .cpp to allow C++ to get an instance of the cppimp class------
cppns::cppInterface *ClassFactory::CreateImpl()
{
return GetImplObject();
}
This code correctly allows me to call CreateImpl to get an implementation of the interface that contains the Start method. My issue is that I'm trying to force the whole CLR/.NET loading and executing into an AppDomain that is not the default AppDomain. I can create a secondary AppDomain using the following code:
CComPtr<ICorRuntimeHost> pRuntimeHost;
//Retrieve a pointer to the ICorRuntimeHost interface
HRESULT hr = CorBindToRuntimeEx(
L"v2.0.50727", //Retrieve last version before 4.0.
// NULL, //Retrieve latest version by default
L"wks",
STARTUP_LOADER_OPTIMIZATION_SINGLE_DOMAIN | STARTUP_CONCURRENT_GC,
CLSID_CorRuntimeHost,
IID_ICorRuntimeHost,
(void**)&pRuntimeHost.p
);
hr = pRuntimeHost->Start();
DWORD dwAppDomainId = 22;
WCHAR domainName[80 + 1];
swprintf(domainName, 80, L"%s-%ld",L"NoDefaultDomain", dwAppDomainId);
CComPtr<IUnknown> pUnknownAppDomain;
hr = pRuntimeHost->CreateDomainEx(domainName, NULL, NULL, &pUnknownAppDomain);
CComPtr<_AppDomain> pAppDomain;
hr = pUnknownAppDomain->QueryInterface(__uuidof(_AppDomain), (VOID**)&pAppDomain.p);
BSTR bstrFriendlyName;
hr = pAppDomain->get_FriendlyName(&bstrFriendlyName);
if (SUCCEEDED(hr))
{
_bstr_t bstrFriendlyNameWrap(bstrFriendlyName, false);
}
_bstr_t bstrAssemblyName("InteropCode");
CComPtr<_Assembly> pAssembly;
hr = pAppDomain->Load_2(bstrAssemblyName, &pAssembly);
BSTR bstrFullName;
hr = pAssembly->get_FullName(&bstrFullName);
if (SUCCEEDED(hr))
{
_bstr_t bstrFullNameWrap(bstrFullName, false);
std::cout << "Assembly name is: " << bstrFullNameWrap << "\n";
}
Every attempt of getting the factory to return to me an interface to cppns::cppInterface within this secondary application domain has failed. I have even attempted to create a secondary factory that is a C# class that returns the pointer to the implemented interface so that an Invoke call on the Assembly would hopefully cause the rest of the code to execute in the AppDomain that I loaded the Assembly into but the Invoke returns an IDispatch pointer that I can't seem to map back into any type of C++ pointer on my interface.
namespace cppns
{
public ref class NetFactory
{
public:
NetFactory()
{
}
cppInterface *CreateInterop()
{
return GetImplObject();;
}
};
}
Is there another way to get everything to run in a secondary AppDomain or is the IDispatch pointer usable in calling the Start method?
I have managed to get most of the .NET stuff running in another domain. It seems like there is no way to get the CLI layer to run in anything other than the default AppDomain.
To make this work I needed to make the class that sits within both appdomains derive from MarshalByRefObject. In my example above that meant I had to change MyInternalCSharpClass so that it derived from MarshalByRefObject. It was also nessary to made the objects sent and returned from MyInternalCSharpClass also derive from MarshalByRefObject. Finally I these same objects that were passed and returned had to have the [Serializable] property and to also mark all their private variables public. Note if the classes being transferred though the AppDomains are already using the Serializable attribute you can use [XmlIgnore] on each formally private variable to avoid changing the serialization that is being done.
Now that everything can be moved between the AppDomains I created a second AppDomain by doing the following:
bool CreateInstanceInAppDomain(const char *pcAppDomainName)
{
bool bRtn = false;
gcroot<String^> csStrAppDomainName (gcnew String(pcAppDomainName));
mAppDomain = AppDomain::CreateDomain(csStrAppDomainName);
delete csStrAppDomainName;
Object^ MyInternalObject = mAppDomain->CreateInstanceAndUnwrap("AssemblyName", "ClassNameSpace.MyInternalCSharpClass");
mInternalClassAccess = dynamic_cast<MyInternalCSharpClass^>(MyInternalObject);
if (mInternalClassAccess)
{
bRtn = true;
}
return bRtn;
}