Common Visual Basic/Studio Components
Have the requirement to distribute all/nearly all of the common controls and components included with VB as part of a build update for a number of simple VB applications with no documented requirements, no packaged installs, and no ability to distribute them locally. Thus .EXE's sitting on shares, people that don't know what they require, and future items like this showing up as well. If you're flashing back to 3.1 environments, take a deep breath.
I have been told that these require your typical basic and included components that come with VB (but no custom or 3rd party controls or .DLLs), your RichTxt, your DataGrid, and your ComCtl's of the world -- but not necessarily which ones. I am assuming my best source is to pull from the latest Visual Studio or VB service pack and that my best bet is to simply install all controls available.
As the SP is meant to update existing installs of VB or VS, it wants to look for a VB or VS install, and is really meant to update the application and supporting files, so that when you build an install, you're dealing with the latest components. As I'm looking to take all the components and update a system vs. a VB/VS install, it appears that my best bet is to extract the SP, and then each of the supporting .CAB files in the SP that include the component groupings (ie. RichTxt, DataGrid, etc), and then execute each of the .INFs found in each of the .CABs (or repackage in the same manner).
My question:
Is there essentially a public redist package for the common VB components in the same manner as there's the bulk grouping and install for MDAC? (not speaking of the VB runtime itself) And if not, has any been presented with this type of scenario?
Just curious if there is a public canned install vs. having to kick of 15-20 .INF installs, whether it gets repackaged or is just run silent.
In essence the plan is to distribute all common controls and components from the VB CD/SP due to the lack of requirements and potential that we may not even have access to the .EXE's or the developers to analyze and identify their specific requirements on their own. Not fun, far from ideal, but needed in this scenario. Sometimes a hammer is all you have...
Thoughts?
I have been told that these require your typical basic and included components that come with VB (but no custom or 3rd party controls or .DLLs), your RichTxt, your DataGrid, and your ComCtl's of the world -- but not necessarily which ones. I am assuming my best source is to pull from the latest Visual Studio or VB service pack and that my best bet is to simply install all controls available.
As the SP is meant to update existing installs of VB or VS, it wants to look for a VB or VS install, and is really meant to update the application and supporting files, so that when you build an install, you're dealing with the latest components. As I'm looking to take all the components and update a system vs. a VB/VS install, it appears that my best bet is to extract the SP, and then each of the supporting .CAB files in the SP that include the component groupings (ie. RichTxt, DataGrid, etc), and then execute each of the .INFs found in each of the .CABs (or repackage in the same manner).
My question:
Is there essentially a public redist package for the common VB components in the same manner as there's the bulk grouping and install for MDAC? (not speaking of the VB runtime itself) And if not, has any been presented with this type of scenario?
Just curious if there is a public canned install vs. having to kick of 15-20 .INF installs, whether it gets repackaged or is just run silent.
In essence the plan is to distribute all common controls and components from the VB CD/SP due to the lack of requirements and potential that we may not even have access to the .EXE's or the developers to analyze and identify their specific requirements on their own. Not fun, far from ideal, but needed in this scenario. Sometimes a hammer is all you have...
Thoughts?
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
MSIMaker
19 years ago
Well I think I know what you mean.
I think that you should try to download the VB runtimes that you need and install them as a seperate entity.
Remember that MS says that if you use the highest version of runtimes that all previously required versions are covered as MS DLL's are backward compatible.
Don't believe that for a second of course and test everything to the max.
There is no way to install multiple versions of VB or VC runtimes or MDAC so start at the highest version and work backwards is the best bet. Remember that the version you install will be the one used by all the apps that make calls to those runtimes.
I think that you should try to download the VB runtimes that you need and install them as a seperate entity.
Remember that MS says that if you use the highest version of runtimes that all previously required versions are covered as MS DLL's are backward compatible.
Don't believe that for a second of course and test everything to the max.
There is no way to install multiple versions of VB or VC runtimes or MDAC so start at the highest version and work backwards is the best bet. Remember that the version you install will be the one used by all the apps that make calls to those runtimes.
Posted by:
cjr888
19 years ago
Actually, better explanation.
Not sure which we need, but know that the groupings are limited to those default to VB CD distribution.
No global redist package exists for an OS level installation of all or some of those groupings.
VB and VS service packs exist to update VS and VB installs, but meant to simply drop all related components and .CABs to Program Files\Visual Basic\<supporting directories> -- not install/register, just drop down to make available for when creating a package and you need to include them.
If I take the VS SP6 package meant to update the application and OS, I can't install it (for my needs), but I can extract the service pack. Within the service pack, if extracted, are 28 cab files, for the common groupings, such as comct332.cab, comctl32.cab,. comdlg32.cab, mschrt20.cab., msdatgrd.cab, etc.. If extracted, the included .INF is actually meant for OS installation. So I could extract all .CABs, and execute 28 .INF files to install/register all.
This is our 'use a hammer' approach, since we won't have the ability to (1) identify how many of these applications exist, or when they are added, and more importantly, (2) if appA requires comctl + msDataGrid and if appB requires say FlexGrid and DataList, we're planning on installing all, because we're in a position where we don't have a choice, and since these applications won't actually reside on any of the XP workstations. Crappy situation, nothing more, nothing less.
Anyone aware of a public redist package in the same manner as MDAC or XML or other grouped components? The VB runtimes themself are just the runtime and some OLE items.. Probably going to throw a call into Microsoft, but figured I'd inquire here first. Have a feeling I'm just kicking off 28 .INF installs via rundll32, whether its just 28 seperate executions, or repackaged into a supporting installation.
Not sure which we need, but know that the groupings are limited to those default to VB CD distribution.
No global redist package exists for an OS level installation of all or some of those groupings.
VB and VS service packs exist to update VS and VB installs, but meant to simply drop all related components and .CABs to Program Files\Visual Basic\<supporting directories> -- not install/register, just drop down to make available for when creating a package and you need to include them.
If I take the VS SP6 package meant to update the application and OS, I can't install it (for my needs), but I can extract the service pack. Within the service pack, if extracted, are 28 cab files, for the common groupings, such as comct332.cab, comctl32.cab,. comdlg32.cab, mschrt20.cab., msdatgrd.cab, etc.. If extracted, the included .INF is actually meant for OS installation. So I could extract all .CABs, and execute 28 .INF files to install/register all.
This is our 'use a hammer' approach, since we won't have the ability to (1) identify how many of these applications exist, or when they are added, and more importantly, (2) if appA requires comctl + msDataGrid and if appB requires say FlexGrid and DataList, we're planning on installing all, because we're in a position where we don't have a choice, and since these applications won't actually reside on any of the XP workstations. Crappy situation, nothing more, nothing less.
Anyone aware of a public redist package in the same manner as MDAC or XML or other grouped components? The VB runtimes themself are just the runtime and some OLE items.. Probably going to throw a call into Microsoft, but figured I'd inquire here first. Have a feeling I'm just kicking off 28 .INF installs via rundll32, whether its just 28 seperate executions, or repackaged into a supporting installation.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.