about com and interopability

[henit]

i first want to apologize for some silly things i might write, cause
all this c++, com and c# is new to me.
i'm currently writing a project that his aim is to load some general
com object in runtime, when this com object is not in registry(don't
ask why...), and his name and path is unknown till runtime. i want to
be able to invoke his methods and to advise to it's events, and to do
it in an easy elgant dot net style way. so what i did so far was to
write a com object (in c++)which loads an other com object in runtime
using Loadlibrary, and i simulate invoke calling.
this com object aim is to get rid of all the dirty uneasy to be done in
c# job. using tlbimport i'm going to warp me com object with c# class.
now comes my questions:
a. reason why i didn't write directly a c# class is that i found that
in this dynamic load of completely mysterious com object i have to use
meny c++ macros, structures, interfaces etc and it was very
inconvenient. was i wrong? is there an easyer way?
b. i want my c# class to pass an object[] to my com so that it could
use them as DISPARAMS, also meaning that some of this objects should
return values to my c# class.
what type should my com class recive and what type should my c# class
pass to do that?
c. i want my c# class to catch the mysterious com object events using
delegates. how can i implement thet feature?
d. and a general one: is it true that there is a diffrence between com
object that was built under vs6 or one that was built under .Net?
something to do with lake of manifast? could it be that some .net
classes don't support the first type?

thanks a lot!
henit

[Nicholas Paldino [.NET/C# MVP]]

Henit,

I think you are going about this the wrong way. Windows XP supports
registration-free COM, meaning that you can place the DLL in the same
directory as your application and it will work just fine.

What you are doing with LoadLibrary is downright wrong. You should
always register a COM object on the system. If you don't, then you are
simply asking for trouble, and going down a path which is not recommended or
supported.

Check out this article in MSDN magazine for more information about
reg-free COM and how to use it with .NET. You can use it with your C++ COM
dll, as it is a matter of creating a manifest file:

http://msdn.microsoft.com/msdnmag/is...04/RegFreeCOM/

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
<he***@gteko.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

i first want to apologize for some silly things i might write, cause
all this c++, com and c# is new to me.
i'm currently writing a project that his aim is to load some general
com object in runtime, when this com object is not in registry(don't
ask why...), and his name and path is unknown till runtime. i want to
be able to invoke his methods and to advise to it's events, and to do
it in an easy elgant dot net style way. so what i did so far was to
write a com object (in c++)which loads an other com object in runtime
using Loadlibrary, and i simulate invoke calling.
this com object aim is to get rid of all the dirty uneasy to be done in
c# job. using tlbimport i'm going to warp me com object with c# class.
now comes my questions:
a. reason why i didn't write directly a c# class is that i found that
in this dynamic load of completely mysterious com object i have to use
meny c++ macros, structures, interfaces etc and it was very
inconvenient. was i wrong? is there an easyer way?
b. i want my c# class to pass an object[] to my com so that it could
use them as DISPARAMS, also meaning that some of this objects should
return values to my c# class.
what type should my com class recive and what type should my c# class
pass to do that?
c. i want my c# class to catch the mysterious com object events using
delegates. how can i implement thet feature?
d. and a general one: is it true that there is a diffrence between com
object that was built under vs6 or one that was built under .Net?
something to do with lake of manifast? could it be that some .net
classes don't support the first type?

thanks a lot!
henit