 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / COM / September 2004DCOM Classes not visible in DCOMCnfg
Hi, I created a dcom test application with a class and a form and an apllication, which calls the class of my test application via dcom. That worked right away. When integrating the class in my main project, I encountered the problem, that the class didn't show up in dcomcnfg. All the settings of my test application and my main project are the same (activex-exe, Remote Server Files option, ...). I tried recompiling, cleaning the registry from any rubish of old compiles of my project, but nothing helped. Is there anything I'm missing? Thanks Sascha dcomcnfg displays "applications" rather than "classes" Sascha. However, it identifies these by their ProgID and an AppID GUID that looks identical to a ClsID GUID in that component. Hence it can be a little confusing. When dcomcnfg starts up, it looks for an existing AppID for your DCOM server in the registry. If it can't find one then it takes the first class that it finds in your component and uses its ClsID to create an AppID. This means that the chosen class can appear random. We have a number of DCOM servers and dcomcnfg seems to pick a different class each time. However, this isn't a problem. The DCOM settings apply to the "application" (i.e. the whole DCOM server) so it doesn't matter which class ProgID you select -- there will only be one displayed for your server. You were simply looking for the wrong one. Tony Proctor > Hi, > [quoted text clipped - 14 lines] > Thanks > Sascha Hi Tony, > [...] The DCOM settings apply to the "application" (i.e. the whole DCOM > server) so it doesn't matter which class ProgID you select -- there will > only be one displayed for your server. You were simply looking for the wrong > one. ok, thanks for the explanation. Even though DCOM as a concept is easy to understand, there is more depth to it, when you implement it. :o| Mayby you could help me understand another problem: My DCOM client can not create instances of my dcom server class as long as I run the dcom server appliction within VB IDE. Once I compile it, there is no problem. Running the server in VB IDE give runtime error 430. The odd thing is, executing 'set objectVar = CreateObject(...)' in the client works (where objectVar is a variable of type Object). The class is instanciated. The problem arrises when calling 'set classVar = CreateObject(...)', where classVar is of the type of the class exposed by dcom. Do you know what I mean? Why is there a difference between the compiled and not compiled version of my server app? Regards, Sascha I'm afraid don't understand the difference between your 2 CreateObject() calls Sascha. CreateObject will always return an object reference, and so must be stored in a object variable. Tony Proctor > Hi Tony, > [quoted text clipped - 21 lines] > Regards, > Sascha > I'm afraid don't understand the difference between your 2 CreateObject() > calls Sascha. CreateObject will always return an object reference, and so > must be stored in a object variable. My fault, sorry. Ok, I give it another try. The class I try to create is called "SMC.SMCClient". My client application has a reference to the SMC application, which is the DCOM server app. The first variant to instanciate the class is this: dim objVar as object set objVar = CreateObject("SMC.SMCClient","127.0.0.1") The second variant is this: dim smcVar as SMCClient set smcVar = CreateObject("SMC.SMCClient","127.0.0.1") The first variant (with objVar) works in any case. The second variant works only if the smc application has been compiled. Usually that is not a problem, but in my particular case I would like to use the second variant, because I use 'withevents' to capture some events raised by smcclient. To make debugging the smc application I would also like to start the application in VB IDE. This worked before, but obviously I made changes to either the client or the server application that prevents setting smcVar to an instance von SMCClient. I executed 'typename(CreateObject("SMC.SMCClient","127.0.0.1"))' while the smc application was running in VB IDE and it returned 'SMCClient'. Seemingly the instance returned by CreateObject and smcVar are the same, but there must be some difference. I even cleaned the registry and recompiled everything, but without success. I hope that make my problem a little clearer... Regards, Sascha This sounds like a mismatch in the GUIDs Sascha. In other words, the registered version of SMC.SMCClient doesn't match the version being used within your IDE. Are you running a "project group" containing the SMC project, or is it in your Project References? What Compatibility setting are you using? Tony Proctor > > I'm afraid don't understand the difference between your 2 CreateObject() > > calls Sascha. CreateObject will always return an object reference, and so [quoted text clipped - 35 lines] > Regards, > Sascha Hi, > This sounds like a mismatch in the GUIDs Sascha. In other words, the > registered version of SMC.SMCClient doesn't match the version being used > within your IDE. yes, I thought so too (even though this was just a guess, since I'm not an expert for those things). > Are you running a "project group" containing the SMC > project, or is it in your Project References? What Compatibility setting are > you using? Client and Server are seperate project *not* running in a project group. If I want them to run in parallel I fire up two instances of VB IDE. The smc server application is a reference in the client project. The compatibility of the server application is set to binaray compatibility. [Unfortunatly I have to leave the office now, so I won't be able to read your next post until tomorrow. Your question about the project group gave me the idea to try to run the client and server within the same IDE. Maybe that helps. I'll try that tomorrow too.] Thanks so far... Sascha Hi, i got it. during compilation of the server app I sometimes had trouble compiling to exe, because vb said, the file was locked. Moving the binary compatible version of the server app to another location solved the compile problem. But then I had the other problem described in my prior post. The solution is: compile the exe and then copy the exe to the location where the binary compatible version is. That's it. I don't know why it's like that, but for some reason my client app looks at the (outdated) binary compatible version instead of the registered original server app, when I start client and server from vb ide. Maybe vb ide always useses the typelib of the binary compatible version? I don't know (even though that wouldn't sound too odd...). Thanks Tony for your hints. Regards, Sascha |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.