[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.interop

Problems creating DCOM server in C#; urgent...

czapkofan

7/10/2007 9:52:00 PM

Hello,
I need to create a DCOM server in C# with a friend, to be accessible
for a client application with embedded VBS. We started with a "Hello
world" article at

http://blogs.msdn.com/adioltean/archive/2004/06/18/1...

but, unfortunately, it seems to work only partially for us, even after
quite a few days of fighting with the problem and googling and MSDN
searching :/ The application can be succesfully run from the local
computer (using a simple CreateObject VBS script running under WSH),
but throws an exception when run remotely, bailing out on the line
where we set ApartmentState (either as a property, or calling the
SetApartmentState() method). It doesn't run properly at all if we
remove the ApartmentState setting line.

How can we make it work? Or maybe there is some other, maybe easier
way to create the server than the method described in the article?
It's very important for us to make it work, we'd be grateful for any
help, hints. If we should provide some more info, please tell us.

- The server computer is WinXP, the client computer will also be WinXP
but we have to do testing on Win2000.

- A "TestDCOM.exe" application (kind of a DCOM-ping) from
http://support.microsoft.com...
works for us, and does get succesfully invoked from a .vbs script on
the client as well. We have merged the registry settings from this
application with those created after following the "Hello world"
article and we're setting them both on the server and client
(regarding dcomcnfg.exe).

- Btw, we have no background in D/COM; still, we've already learned
some basics when trying to solve the problem.

Greetings
Mateusz Czaplinski
1 Answer

czapkofan

7/12/2007 11:16:00 PM

0

Found some way which I hope will solve our problem: to create a DLL in
C# and host it with a "DLL Surrogate". This way we shouldn't have
problems with playing with Windows Services (as required(?) in EXE &
out-of-process) and will be able to use *D*COM (problematic with a DLL/
in-process, as it normally doesn't have an AppID). Huzzah. But it
required truly *lots* of RTFMing on Google & MSDN.