in-proc ==>> Out-of-proc
-
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?
-
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?
Yes, of course. Your new component should have the same CLSID (or ProgID, translated into necessary CLSID) and the same set of interfaces as the old DLL-component. There is a "location transparency" rule in COM. Look at MSDN for more information about this. With best wishes, Vita
-
Yes, of course. Your new component should have the same CLSID (or ProgID, translated into necessary CLSID) and the same set of interfaces as the old DLL-component. There is a "location transparency" rule in COM. Look at MSDN for more information about this. With best wishes, Vita
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.
-
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.
I have no problem at all. I made the VB's Server.dll, VC's Server.exe and testing Project1.exe. Tested object has one method xxx in VB server
Public Sub xxx()
MsgBox "xxx subroutine is called"
End Suband in VC server
STDMETHODIMP CClass::xxx()
{
// TODO: Add your implementation code here
MessageBox(NULL,"ATL xxx is called", "ATL", MB_OK);
return S_OK;
}and testing code in Project1 project
Sub Main()
Dim x As Server.Class
Set x = CreateObject("Server.Class")
x.xxx
End SubWhen i register some COM server, I have relevant message: if VB, then VB, if VC, then VC. I.e. >regsvr32 Server.dll >Project1.exe Having ... xxx subroutine is called >regsvr32 /u Server.dll >Server.exe -RegServer >Project1.exe Having ... ATL xxx is called >Server.exe -UnRegServer There is no magic. It's possible that you have a mistake. I also firstly made a mistake - I have mixed up the coclass and interface IDs. And I had "Type mismatch" :) With best wishes, Vita
-
I have no problem at all. I made the VB's Server.dll, VC's Server.exe and testing Project1.exe. Tested object has one method xxx in VB server
Public Sub xxx()
MsgBox "xxx subroutine is called"
End Suband in VC server
STDMETHODIMP CClass::xxx()
{
// TODO: Add your implementation code here
MessageBox(NULL,"ATL xxx is called", "ATL", MB_OK);
return S_OK;
}and testing code in Project1 project
Sub Main()
Dim x As Server.Class
Set x = CreateObject("Server.Class")
x.xxx
End SubWhen i register some COM server, I have relevant message: if VB, then VB, if VC, then VC. I.e. >regsvr32 Server.dll >Project1.exe Having ... xxx subroutine is called >regsvr32 /u Server.dll >Server.exe -RegServer >Project1.exe Having ... ATL xxx is called >Server.exe -UnRegServer There is no magic. It's possible that you have a mistake. I also firstly made a mistake - I have mixed up the coclass and interface IDs. And I had "Type mismatch" :) With best wishes, Vita