I have an out-of-proc COM server. In one of the method of my COM server, I need Thread Id of the client application who is calling the method. Is there any way to get thread id fo client process in COM server code? Regards.

You are right, but this is not a solution for the problem. I was looking for an API to get thread id of COM client.

I have an out-of-proc COM server. In one of the method of my COM server, I need Thread Id of the client application who is calling the method. Is there any way to get thread id fo client process in COM server code? Regards.

Why don't you opt for a normal Dll for Autoupdate.exe. Expose a function say "UpdateApp(...)" from that Dll, and it will have 2 parameters as you said. Whenever you have to update/upgrade/change the EXE/module, call that function of DLL. Please tell me whether my understanding is wrong.

Thanks for your efforts. Can you please send us the code of both VB and VC server and client samples that you have written? This will help us in locating problem at our end. Regards.

Hi, Please suggest regarding following trouble: Create a COM component "InProcVB.dll" as in-proc DLL in VB exposing some interfaces and methods . Write its client as "clientVB". Write another COM component as "OutOfProc.exe" as out-of-proc exe server in VC. This has same interface/class/InterfaceIDs/ClassIDs as that of "InProcVB.dll". This is written with purpose of replacing "InProcVB.dll". And, the expectation is that client need not re-compile. (As defined by rule "Location transparency of COM). After developing "OutOfProc.exe", we unregistered "InProcVB.dll", and registered "OutOfProc.exe". Executed "clientVB" without any change. It gave error type-mismatch. The error point was: Dim objSrvClass as SrvClass set SrvClass = CreateObject("Server.Class") --> Problem: Type mismatch. If I change code as Dim objSrvClass as Object set SrvClass = CreateObject("Server.Class") It works well. Please suggest.

Thanks. I am facign following trouble: Create a COM component "InProcVB.dll" as in-proc DLL in VB exposing some interfaces and methods . Write its client as "clientVB". Write another COM component as "OutOfProc.exe" as out-of-proc exe server in VC. This has same interface/class/InterfaceIDs/ClassIDs as that of "InProcVB.dll". This is written with purpose of replacing "InProcVB.dll". And, the expectation is that client need not re-compile. (As defined by rule "Location transparency of COM). After developing "OutOfProc.exe", we unregistered "InProcVB.dll", and registered "OutOfProc.exe". Executed "clientVB" without any change. It gave error type-mismatch. The error point was: Dim objSrvClass as SrvClass set SrvClass = CreateObject("Server.Class") --> Problem: Type mismatch. If I change code as Dim objSrvClass as Object set SrvClass = CreateObject("Server.Class") It works well. Please suggest.

The solution for this is that you should club separate calls into a single call. For example: Suppose you have a collection of 100 items, and collection's object has 4 attributes each. To display all the properties, your client is doing something like this: For each item of collection: { Get object get first prop of object get second prop of object get third prop of object get fourth prop of object } So, you are making 5 *100 = 500 calls to COM server. Instead you should define prototype like this: Collection->GetAllproperties([out] Variantarray) So, single call to COM server will achieve this. Regards.

I have a query regarding component versioning. I had a component named "Old_VC_Exe_Component" exposed as an STA, out-of proc COM server, developed in VC++. This is for our internal use and not for client. "Old_VC_Exe_Component" is wrapped by another component "Old_VB_Dll_Component_Wrapper" which is in-proc COM server developed in VB, and this is exposed as SDK to client. Now we are planning to provide new version of our product. In new version, we are thinking of removing the wrapper layer. That is we want to expose "Old_VC_Exe_Component" to client (as "New_VC_Exe_Component") instead of "Old_VB_Dll_Component_Wrapper". We can change server code at server end. And the requirement is that, client of "Old_VB_Dll_Component_Wrapper" SDK should not be required to make any change in his code, when we replace "Old_VB_Dll_Component_Wrapper" by "New_VC_Exe_Component". Can you tell me is this possible? Or what can be the possible issues in doing this?

Here are the results of the test, performed on NT4SP3, Pentium Pro 300Mhz, 128Mb RAM, and a 10Base-T network connection: Early Bound Late Bound Cached In Process 20 ms 90 ms 80 ms Out of Proc 1952 ms 5137 ms 2944 ms Remote 14952 ms 36403 ms 20089 ms

You need to answer following before perfromace measurement: What is type of your server? out-of-proc/in-proc? What interfaces are you using? Dispatch/Dual? What is the frequency of clietn server interaction?

EZ JCom lets you call COM objects from Java. Check http://www.ezjcom.com/

Thanks for your reply. I have a further query: What shall happen to the clients who were using "Old_Component_Wrapper(DLL)" server? Shall they be able to use new "Old_Component(EXE)" without any change in their code??

We have written an ou-of-proc, Free threaded, ATL server. When 4 web users call this server for 5-6 hours, this server hangs, and a new instance of the server is launched in the memory. And the new server also not responds to user calls. Can somebody tell me the possible cause of this trouble?

I have soem queries regarding component versioning. I had a component named "Old_Component" exposed as an STA, out-of proc COM server, developed in VC++. This is wrapped by another component "Old_Component_Wrapper" which is in-proc COM server and exposed to client. Now we are planning to provide new version of our product. In new version, we are thinking of removing the wrapper layer. That is we want to expose "Old_Component" to client instead of "Old_Component_Wrapper". Can you tell me is this possible? Or what can be the possible issues in doing this?

I have soem queries regarding component versioning. I had a component named "Old_Component" exposed as an STA, out-of proc COM server, developed in VC++. This is wrapped by another component "Old_Component_Wrapper" which is in-proc COM server and exposed to client. Now we are planning to provide new version of our product. In new version, we are thinking of removing the wrapper layer. That is we want to expose "Old_Component" to client instead of "Old_Component_Wrapper". Can you tell me is this possible? Or what can be the possible issues in doing this?

I am developing an ASP .Net web service using Visual studio .NET. Can I deploy this service on Netscape web server as well? Regards.

Hi, How can I call my existing MFC based Dll (developed in VC 6) functions/ classes from ATL Web service/ Managed C++ Web service? Atin.

The basic rule of COM says, In COM, once you "publish" an interface contract by shipping a component, the contract is immutable—it cannot be changed in any way. You can not add. You can not delete. You can not modify. But, when you open Microsoft Word 97/98 and Microsoft Word 2000 's .OLB files, you will see that for extending the interfaces, they have added methods to the old interfaces. For example, in MS Word 2000 they have added methods in Application interface, and all the other interfaces. Why So? I feel the right approach is to add new interface if you want to extend an interface. Can somebody tell me its' reason??

We have implemented COM automation server using MFC. MFC Use Nested Class approach to implement COM interface. What We have done is that for each component we have two interface IMyInterface and IDualMyInterface(for VB client) and both interface expose same set of function. IMyDualInterface is implemented in Nested class and IMyInterface is implemented in parent class. All the Call to IMyDualInterface Methods are routed to corrosponding IMyInterface implementation by using METHOD_PROLOGUE_EX Macro (This macro return the parent class pointer i.e.pThis). Now I have to Enhance my com server for this I have to make some changes in my both interface but according to COM rule I can not modify the interface once it is published, as it break the contract with my existing client that are using my previous COM server. I want to Know How I can Enhance my COM server that is using MFC support. regards.