[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
Rob,
I use Wise and what we do for components that need to be registered client side is create a wise setup specifically where just the components get registered and nothing gets copied or "installed". In the Wise Installation System IDE you can set the script to queue a component to be registered from the install directory the setup program is running from(%INST%).
For example:
item: Self-Register OCXs/DLLs
Description=%INST%\\SG20o.ocx
Flags=00000001
end
item: Self-Register OCXs/DLLs
end
So you would queue up as many ocx's and dll's as you need in the script and then run the self register.
The setup exe you create would just need to be in the same directory, or relative directory of the component files(ocx, dll, etc) so it can find them.
Wise sample script attached. Just remove the .txt extension.
[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
Thanks, Dan. I'll give it a try. I've been trying to deal with Wise support for quite some time (not fun). Makes you appreciate AcuCorp's wonderful support.
Since I'm not familiar with Wise, this should be a big help.
Regards,
Rob!
[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
Thanks, Dan. I'll give it a try. I've been trying to deal with Wise support for quite some time (not fun). Makes you appreciate AcuCorp's wonderful support.
Since I'm not familiar with Wise, this should be a big help.
Regards,
Rob!
[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
Rob,
DLL hell is one reason, amongst several, that I look forward to full .NET support in Acucobol-GT. No more DLL hell! Put a .NET component in your directory and just use it.
[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
This scares me a little bit to not get any responses to this. Are people just not distributing ActiveX or are they using regsvr32?
Dan,
I tried your example, but it doesn't do any version checking, which is my main concern. Wise tells me that I need to write a script to check Windows Registry values... Heck, if I'm going to do that, I'll just use Cobol. How do you get around this?
Anyone else doing this?
Rob
[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
I'm trying to understand your versioning issue a little better.
Does this have to do with users wanting to run multiple revisions of your application on the same PC where each revision is tied to a specific(different) version of a control?
If so, we haven't run into this yet, but we may. Our users tend to switch over to a new revision entirely and not use the old one.
You should be able to directly check file version information using the Win32 API function GetFileVersionInfo. This should return information equivalent to what you would see when right clicking on a file in windows file explorer, selecting properties and then clciking the version tab.
[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
I'm trying to understand your versioning issue a little better.
Does this have to do with users wanting to run multiple revisions of your application on the same PC where each revision is tied to a specific(different) version of a control?
If so, we haven't run into this yet, but we may. Our users tend to switch over to a new revision entirely and not use the old one.
You should be able to directly check file version information using the Win32 API function GetFileVersionInfo. This should return information equivalent to what you would see when right clicking on a file in windows file explorer, selecting properties and then clciking the version tab.
[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
Here's a specific example of my problem:
Let's take an example of a standard MS control that users should have on their system, such as MSCOMCT2.OCX. The user might have a brand new version of this control (dated 2005) already registered on their system. We might be distributing a version dated 2003. Before we go and register the 2003 version of the control, I want to be sure that it's the latest. In other words, I DON'T want the 2003 version to be registered if there is a 2005 version already present. This has been known to cause problems - particularly with the application depending on the 2005 version! :-)
But, in contrast, if the user has a 2001 version of the control, we would want to register the 2003 version to ensure that it works.
My main questions are:
1. Is anyone doing this checking (because I think we all should)?
2. If so, how are you doing it?
Sorry if I haven't explained myself as well in the past and if I didn't again...
Rob
[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
Originally posted by Robstan
Let's take an example of a standard MS control that users should have on their system, such as MSCOMCT2.OCX. The user might have a brand new version of this control (dated 2005) already registered on their system. We might be distributing a version dated 2003. Before we go and register the 2003 version of the control, I want to be sure that it's the latest. In other words, I DON'T want the 2003 version to be registered if there is a 2005 version already present. This has been known to cause problems - particularly with the application depending on the 2005 version! :-)
I did not realize this had to do with pre-existing shared components, I thought it was just for components isolated for use by your application. That explains my confusion . ;-)
One warning about the example you describe is the assumption that a newer pre-installed component will work correctly with your application that has been tested with the older version. It might break your app. Yes, it's the lesser of two evils when compared to installing(registering) the old version overtop of the new version, but it still could be a problem.
So how can this DLL hell incompatability issue be avoided?
Here's an MS article that talks about using DLL/COM redirection to handle incompatibility among different versions of the same component:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsetup/html/sidebyside.aspUnder contents, click on the hyperlink labeled "DLL/COM Redirection".
Basically it talks about how you can have a "local" version of a component for use by your application that does not "bump" into the registered one. This will better maintain the integrity of your application. I have not tried this yet myself, but it sounds worth investigating.
Note that this article does explain some important requirements such as the following:
Note: Isolated COM components must be registered properly with the operating system so that each version of the component won't conflict with other versions of the component that may exist. This registration requires that while the implementation of the component can change between versions, such registered COM meta-data as CLSID, ProgID, Type Library, and Threading Model cannot change between versions.
Note: Windows 2000 and Windows 98 Second Edition both support DLL/COM redirection. It is not supported for previous Windows operating systems.
[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
Thanks, Dan. I'll look into it. I also found a product called Thinstall (
http://thinstall.com) that allows for something similar. I'd be interseted to hear other comments on this if anyone else has insight. This is a big obstacle to overcome for Cobol developers in my opinion.
Rob
[Migrated content. Thread originally posted on 16 March 2005]
I have been struggling to find the best way to deploy ActiveX controls with our software. Presently, we install our application in an "Enterprise" manner. What I mean by this is that all of our programs (including controls) are installed on a server and shared by users instead of residing on each PC. To install our software, you would just load the CD on the server and that's it. When users logon, we register the Active-X controls on each of their PCs, but they remain on the server (\\\\servername\\...).
My problem is that I am trying to determine the best way to handle version checking of the controls. I've considered just checking the windows registries myself and determining whether to register them or not, but I feel it is better to use a 3rd party product to handle this. This is because I think that it will be an easier job on my behalf and also I have the presence of mind that it is being done properly. In essence I am looking for a 3rd party product that can register (if version is newer) controls from a simple .exe. Does anyone know of one?
Or is anyone doing this in a different manner? I'd be curious to see how other Active-X/COM developers are handling this situation. Is everyone just checking windows registries and executing regsvr32?
Many of the installation packages I've looked into including Wise have features similar to this, but always want to "install" something. At the time of the install, we don't want to register anything because we are on the server. We want to have the registration handled at a different time.
I guess this problem is nicknamed "DLL hell"? :-)
Rob
Thanks, Dan. I'll look into it. I also found a product called Thinstall (
http://thinstall.com) that allows for something similar. I'd be interseted to hear other comments on this if anyone else has insight. This is a big obstacle to overcome for Cobol developers in my opinion.
Rob
