This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: COM Server and Proxy issue
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 22, 2008
09:39 PM
COM Server and Proxy issue
Hey everyone,
Little background first: up to this point, I've had an Installshield 6.2 project that has included a COM server in it as an MSI, and it had some VB Exe's which was used to register and install the MSI (the source code for the EXEs are long gone). This COM Server package only had dlls, not their tlbs (type libraries) in it, i.e. we'd copy the dlls into the com server package and export it as an MSI; then bring in the MSI into the installshield project. My task has been twofold: one, to now include the tlbs and two, to upgrade to installshield 2008 (in the end).
I've since upgraded to Installshield X. What I did first was to copy the dlls AND their tlbs into the com plus server package, then included the COM Server itself into the Installshield X project (by selecting it in the Component Services view). I then selected both the Proxy and Server installation types and set the condition of the Proxy to COMPLUSTYPE = "Proxy" and the condition of the Server option to COMPLUSTYPE = "Server". Basically what this did was brought each component into the components view, a server and proxy copy of each tlb and dll, i.e. say the component name was Connection.dll and it has a Connection.tlb file, there is now a ProxyFile1 AND ServerFile1 with Connection.dll in it, ProxyFile2 AND ServerFile2 with Connection.tlb in it.
In Installshield X, I had to do very little after selecting the package in the components view and making the above adjustments; I think all I did was set the files to self register and everything seemed to work great. Now that I'm in the process of trying to upgrade to Installshield 2008, I've noticed that it has taken a long time to install and gets "stuck" at the registering of the type libraries/registering of the COM server, but no errors seem to appear in the log file (it does continue to the next step after a while and interestingly enough the cancel button doesn't seem to do anything when it is "stuck"). I tried to reduce the time by moving the type library entries from the Registry table to the TypeLib table (which is not recommended); this cut the install time in half, from an hour and a half to 45 minutes, so it seems like a step in the right direction. Installshield X seemed to take about 15-20 minutes to install so it seems like something is wrong with the setup in Installshield 2008, i.e. something changed with the new version (?)
I extracted the COM info for each file ahead of time before making the build (also setting the "extract com info at build" to NO). After doing this, I noticed that, using the sample above, a typelib entry was entered in the Typelib table for the ProxyFile1, ProxyFile2, ServerFile1, and ServerFile2, each having the same typelib GUID. It seems kind of odd to me that each tlb component generated a Typelib GUID in addition to the one its corresponding dll generated.
I guess at this point I'm confused about what registry data and com registration data a dll should be extracting versus its corresponding tlb. The four typelib entries (one for the proxy dll, proxy tlb, server dll, and server tlb) that are basically the same GUID seems like duplicate data in the Typelib table, and since the install takes a little while, I'm not sure if there is duplicate data causing issues. I'd like to feel more assured about what is in the Registry and Typelib tables.
Does anyone have any samples of an Installshield MSI project that includes a com package that incorporates both a proxy and server installation? If not, can anyone shed some light on how the registry values and typelib tables should look? I'm not asking what the GUIDs should be, of course, I know what the GUIDs should be for each component, it's more like what the registry data and com registration views of the components should show, i.e. should the tlb have interface and classid entries in its Registry Data view or just Typelib entries or...? How does this compare to its dll registry data view entries, etc. Also, should the proxy tlb components have the same registry data as the server tlb components...I'm assuming they should.
Does anyone know of any documents/samples that could help me?
Thanks in advance.
Little background first: up to this point, I've had an Installshield 6.2 project that has included a COM server in it as an MSI, and it had some VB Exe's which was used to register and install the MSI (the source code for the EXEs are long gone). This COM Server package only had dlls, not their tlbs (type libraries) in it, i.e. we'd copy the dlls into the com server package and export it as an MSI; then bring in the MSI into the installshield project. My task has been twofold: one, to now include the tlbs and two, to upgrade to installshield 2008 (in the end).
I've since upgraded to Installshield X. What I did first was to copy the dlls AND their tlbs into the com plus server package, then included the COM Server itself into the Installshield X project (by selecting it in the Component Services view). I then selected both the Proxy and Server installation types and set the condition of the Proxy to COMPLUSTYPE = "Proxy" and the condition of the Server option to COMPLUSTYPE = "Server". Basically what this did was brought each component into the components view, a server and proxy copy of each tlb and dll, i.e. say the component name was Connection.dll and it has a Connection.tlb file, there is now a ProxyFile1 AND ServerFile1 with Connection.dll in it, ProxyFile2 AND ServerFile2 with Connection.tlb in it.
In Installshield X, I had to do very little after selecting the package in the components view and making the above adjustments; I think all I did was set the files to self register and everything seemed to work great. Now that I'm in the process of trying to upgrade to Installshield 2008, I've noticed that it has taken a long time to install and gets "stuck" at the registering of the type libraries/registering of the COM server, but no errors seem to appear in the log file (it does continue to the next step after a while and interestingly enough the cancel button doesn't seem to do anything when it is "stuck"). I tried to reduce the time by moving the type library entries from the Registry table to the TypeLib table (which is not recommended); this cut the install time in half, from an hour and a half to 45 minutes, so it seems like a step in the right direction. Installshield X seemed to take about 15-20 minutes to install so it seems like something is wrong with the setup in Installshield 2008, i.e. something changed with the new version (?)
I extracted the COM info for each file ahead of time before making the build (also setting the "extract com info at build" to NO). After doing this, I noticed that, using the sample above, a typelib entry was entered in the Typelib table for the ProxyFile1, ProxyFile2, ServerFile1, and ServerFile2, each having the same typelib GUID. It seems kind of odd to me that each tlb component generated a Typelib GUID in addition to the one its corresponding dll generated.
I guess at this point I'm confused about what registry data and com registration data a dll should be extracting versus its corresponding tlb. The four typelib entries (one for the proxy dll, proxy tlb, server dll, and server tlb) that are basically the same GUID seems like duplicate data in the Typelib table, and since the install takes a little while, I'm not sure if there is duplicate data causing issues. I'd like to feel more assured about what is in the Registry and Typelib tables.
Does anyone have any samples of an Installshield MSI project that includes a com package that incorporates both a proxy and server installation? If not, can anyone shed some light on how the registry values and typelib tables should look? I'm not asking what the GUIDs should be, of course, I know what the GUIDs should be for each component, it's more like what the registry data and com registration views of the components should show, i.e. should the tlb have interface and classid entries in its Registry Data view or just Typelib entries or...? How does this compare to its dll registry data view entries, etc. Also, should the proxy tlb components have the same registry data as the server tlb components...I'm assuming they should.
Does anyone know of any documents/samples that could help me?
Thanks in advance.
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 22, 2008
10:42 PM
I'm afraid I haven't done DCOM/ComPlus/Component Services in years. If you search through my old threads from around 2003-2005 you'll probably get a lot of hits as I was active in it back then.
Basically the export MSI functionality sucks. Instead author of your components with COM extraction.
Now let's talk about the Component Services view under Server Configuration. I don't like it, think it sucks and don't use it. I don't like the concept of having to first install the COM+ application on my development environment before IS will examine it and author the behavior. This is really old school.
Instead I wrote some ComAdmin (automation object model ) script back in the day to do all this programatically. Of course that's really old school thinking also but hey, it worked.
I'm afraid I can't help much more. I've forgotten so much of this since .NET WebServices and Remoting really rock.
Basically the export MSI functionality sucks. Instead author of your components with COM extraction.
Now let's talk about the Component Services view under Server Configuration. I don't like it, think it sucks and don't use it. I don't like the concept of having to first install the COM+ application on my development environment before IS will examine it and author the behavior. This is really old school.
Instead I wrote some ComAdmin (automation object model ) script back in the day to do all this programatically. Of course that's really old school thinking also but hey, it worked.
I'm afraid I can't help much more. I've forgotten so much of this since .NET WebServices and Remoting really rock.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 22, 2008
10:48 PM
Do a forum search for my last name ( don't match exact name ) with a keyword of ComAdmin. You should get 10 hits back from various threads that have a lot of tips and code samples.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 23, 2008
01:35 AM
Thanks for you response.
Couple of things.
First, I'm seeing a lot of code regarding creating the complus server package through installscript functions and code to add the component dlls into the package, which is fine, but what do I do on the client side if the client piece is being installed, i.e. how do I create the proxy. I know that in the installshield X version that I had created, the client was able to connect to the server without having any kind of complus package installed on the client. This is kind of a black box to me, how the client is able to know what the server is and how to communicate with it. I think I need more information on what exactly would make up a proxy on the client side.
Also, regarding the complus server package, most of the sample code I've seen talks about creating the package and then adding the components to the package. None of them seem to mention incorporating tlb files. How would I incorporate tlb files into the complus server package, or does this not make sense?
Please forgive my ignorance on these issues.
Couple of things.
First, I'm seeing a lot of code regarding creating the complus server package through installscript functions and code to add the component dlls into the package, which is fine, but what do I do on the client side if the client piece is being installed, i.e. how do I create the proxy. I know that in the installshield X version that I had created, the client was able to connect to the server without having any kind of complus package installed on the client. This is kind of a black box to me, how the client is able to know what the server is and how to communicate with it. I think I need more information on what exactly would make up a proxy on the client side.
Also, regarding the complus server package, most of the sample code I've seen talks about creating the package and then adding the components to the package. None of them seem to mention incorporating tlb files. How would I incorporate tlb files into the complus server package, or does this not make sense?
Please forgive my ignorance on these issues.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 23, 2008
06:10 AM
I'm afraid I don't have access to the code baseline that I used to work on. I could possibly ask some old friends and see where it gets me.
I don't know all the ways this could be designed because I didn't write the vb6 code, but I seem to remember server dll's and something they called proxy stub's. On the client side I don't think I did anything except register a bunch of DLL's and write to the registry a couple of values that was used to point it at a server.
I don't know all the ways this could be designed because I didn't write the vb6 code, but I seem to remember server dll's and something they called proxy stub's. On the client side I don't think I did anything except register a bunch of DLL's and write to the registry a couple of values that was used to point it at a server.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 23, 2008
08:04 AM
Hey Chris, thanks for the replies!
Well, I don't want to be a big bother to you, but any help you can give me would help me greatly. At this point, this project (upgrading to Installshield 2008 from Installshield 6.2) has taken MUCH longer than it probably should have, and I can't tell you how happy I'll be when it is done. It will open up a lot of my time to do development on the VB code to enhance the product further and work on other projects, you know, the tasks I'm more used to.
Right now, I'm kind of feeling the pressure on this one, so all help is immensely welcomed.
But as I said, at the same time, I don't want to be a big bother; just would love to get past this last issue I'm having.
Thanks Chris!
Well, I don't want to be a big bother to you, but any help you can give me would help me greatly. At this point, this project (upgrading to Installshield 2008 from Installshield 6.2) has taken MUCH longer than it probably should have, and I can't tell you how happy I'll be when it is done. It will open up a lot of my time to do development on the VB code to enhance the product further and work on other projects, you know, the tasks I'm more used to.
Right now, I'm kind of feeling the pressure on this one, so all help is immensely welcomed.
But as I said, at the same time, I don't want to be a big bother; just would love to get past this last issue I'm having.
Thanks Chris!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 23, 2008
09:39 AM
I'd love to help, but I doubt I can since I don't have a sample COM+ client/server app and integration lab images setup to develop and test against. While this is something I would entertain for a consulting engagement, it's too much plumbing for me to mockup to answer a one-off question.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 23, 2008
10:09 AM
Okay Chris. No problem, thanks for pointing me in the right direction. I should be able to figure things out. 🙂
![](/skins/images/8C9D13A71C7F7695F3262372C0172D68/responsive_peak/images/icon_anonymous_message.png)