Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. COM
  4. in-proc ==>> Out-of-proc

in-proc ==>> Out-of-proc

Scheduled Pinned Locked Moved COM
c++databasecomsysadminquestion
5 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • I Offline
    I Offline
    In At
    wrote on last edited by
    #1

    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?

    V 1 Reply Last reply
    0
    • I In At

      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?

      V Offline
      V Offline
      Vi2
      wrote on last edited by
      #2

      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

      I 1 Reply Last reply
      0
      • V Vi2

        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

        I Offline
        I Offline
        In At
        wrote on last edited by
        #3

        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.

        V 1 Reply Last reply
        0
        • I In At

          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.

          V Offline
          V Offline
          Vi2
          wrote on last edited by
          #4

          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 Sub

          and 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 Sub

          When 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 1 Reply Last reply
          0
          • V Vi2

            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 Sub

            and 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 Sub

            When 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 Offline
            I Offline
            In At
            wrote on last edited by
            #5

            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.

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups