(Somebody with a more thorough grip of COM might persuade GCC to do
this, e.g. through ClrCreateManagedInstance)
The time-consuming task was understanding why the C# loader worked and
the C++ loaded didn't. The problem went away when I used the .NET
2.0.x csc compiler instead of the default .NET 4.0 version - targeting
.NET 2.0 should be good enough. If people need it, they can get the
assemblies from the upstream project.
Needless to say, this is going to be an entertaining project to
CMake-ify. It's a mixed-language project, the C++ is different and
the C# compiler is not the one provided by the Windows SDK.
steve d.
The time-consuming task was understanding why the C# loader worked and
the C++ loaded didn't. The problem went away when I used the .NET
2.0.x csc compiler instead of the default .NET 4.0 version - targeting
.NET 2.0 should be good enough. If people need it, they can get the
assemblies from the upstream project.
Needless to say, this is going to be an entertaining project to
CMake-ify. It's a mixed-language project, the C++ is different and
the C# compiler is not the one provided by the Windows SDK.
Exactly, no more odd custom build jobs!
I'm going to continue to see if gcc can do this. It's a slightly
esoteric subject, so Google does not directly produce solutions - it's
a case where one actually needs to understand how the CLR and COM
interact.
steve d.
OLE/COM Object Viewer for Interface _AppDomain shows
TypeLib={BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}
2.0=mscorlib.dll
win32=C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.tlb
win64=C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorlib.tlb
BED7F4EA-1A96-11D2-8F08-00A0C9A6186D
2.4=mscorlib.dll
win32=C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.tlb
win64=C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorlib.tlb
If you File>View TypeLib... on one of those tlb files, it shows the
equivalent IDL.
[
odl,
uuid(05F696DC-2B29-3663-AD8B-C4389CF2A713),
version(1.0),
oleautomation,
custom(0F21F359-AB84-41E8-9A78-36D110E6D2F9, "System._AppDomain")
]
interface _AppDomain : IUnknown {
HRESULT _stdcall GetTypeInfoCount([out] unsigned long* pcTInfo);
HRESULT _stdcall GetTypeInfo(
[in] unsigned long iTInfo,
[in] unsigned long lcid,
[in] long ppTInfo);
....
But do you really need full the _AppDomain interface + type library,
or will IUnknown suffice? LuaInterfaceLoader.cpp looks quite simple.
I'm not familiar with the luainterface code though.
Thanks for the tips, David: my COM knowledge is somewhere between
rusty and rudimentary.
The rest of the project is pretty straightforward C# that uses
p/invoke to call the Lua DLL.
It would be very good to break the MS dependency because having a
project which has a dependency on a half-gig SDK is wasteful and
inelegant.
steve d.
pd