I'm using a COM DLL from a C# application via an interop wrapper
generated by 'tlbimp.exe'. That all works fine, I can fire off methods
and things happen as they should.
My issue is that I want my application to check both that the COM DLL
is registered on the system and its version is acceptable. I envisage
a bit of code at the beginning of the application's runtime that
performs these checks.
I've got a 'soup' of ideas about how to tackle this. I get the
impression that I can't get the information I'm looking for from the
COM object if it's been instantiated via the interop. I tried this...
MyCOMLib.MyInterface MyInstance = new MyCOMLib.MyInterface();
Assembly myAssembly = Assembly.GetAssembly(MyInstance.GetType());
Console.WriteLine("name=" + SampleAssembly.CodeBase);
But it just gave me the pathname to the interop wrapper whereas I want
the pathname to the DLL that the interop uses.
So then I tried this to get rid of the interop haze in the middle...
Type myType = Type.GetTypeFromProgID("MyCOMLib.MyInterface");
Object myObject = Activator.CreateInstance(myType);
This felt just like instantiating a COM object in C++ with
CreateInstance(). So now I want to do something like a call to the
Platform SDK's GetModuleFileName(), passing in the object reference,
but looking around the framework I can only find the
'FullyQualifiedName' property of the Module class in
System.Reflection. Maybe I can use this somehow?
Armed with this fully qualified filename I was hoping to be able to
feed it into some kind of embedded resource-parsing function in the
framework that would give me the version directly from the file (like
GetFileVersionInfo() does in version.lib). Maybe there's a way of the
framework getting me the version without having to resolve the DLL's
pathname first though?
As for checking whether the COM object is registered at all on the
system at all, I imagine putting an exception check round an
instantiation statement would suffice?
Any comments welcome!
James