PDA

View Full Version : SWDEPEND.INI & ISDEPEND.INI - Problems Resolved - Sort OF



NewsArchive
12-05-1996, 01:00 AM
Ritesh wrote:
>
> Matt Krzysiak <mkrzy@msn.com> wrote
> > I just recently moved from the Microsoft Setup Wizard to InstallShield
> > Express. In the past I have had plenty of problems during the setup
> > process that I was able to trace back to Microsoft's SWDEPEND.INI file.
> I
> > have had to make changes to this file to ensure some controls (like
> Crystal
> > Reports) installed and registered themselves properly. I noticed that
> > there is a SWDEPEND.INI and ISDEPEND.INI file in a directory under the
> > InstallShield directory. Can anyone give me some information on how
> > InstallShield uses these files as opposed to the SWDEPEND.INI in the
> > Windows directory? I am very interested in understanding where
> > InstallShield goes to identify what additional files are needed for each
> > control.
>
> SWDEPEND.INI and ISDEPEND.INI are used during runtime to register files.
> Express does not use any SWDEPEND.INI files from the windows directory.
>
> Ritesh

Like Matt I am moving from the VB4 setupwiz to IS pro, I have tried the
copy of IS supplied with VB4 and am now considering am upgrade to the
Professional version.

But have a number of Queries.

1. I use a number of third Party .OCX's, including one I build myself,
which I would expect to be able to include in the auto. detect feature
of ISPro is this possible and can you point me to where I might find
this information.

2. I notice that IS Pro. does not support auto detect of .VBX files. The
projects I am currently building make use of a number of third party
...VBX's including ones I build myself. Would it be possible to includ
support auto detect of .VBX's.

3. I have noticed that a number of system files are incorrectly added,
during auto detect, from <windir>\system32, these are 16 bit .dll's
which only live in the <windir>\system directory. Is this a bug in the
version which has now been fixed?

4. There does not seem to be any application support for maintaining the
swdepend.ini and isdepend.ini files is this now supported in IS Pro?

Thanks in advance for your help
Martyn

NewsArchive
01-11-1997, 01:00 AM
Martyn Pavey wrote:
>
> Ritesh wrote:
> >
> > Matt Krzysiak <mkrzy@msn.com> wrote
> > > I just recently moved from the Microsoft Setup Wizard to InstallShield
> > > Express. In the past I have had plenty of problems during the setup
> > > process that I was able to trace back to Microsoft's SWDEPEND.INI file.
> > I
> > > have had to make changes to this file to ensure some controls (like
> > Crystal
> > > Reports) installed and registered themselves properly. I noticed that
> > > there is a SWDEPEND.INI and ISDEPEND.INI file in a directory under the
> > > InstallShield directory. Can anyone give me some information on how
> > > InstallShield uses these files as opposed to the SWDEPEND.INI in the
> > > Windows directory? I am very interested in understanding where
> > > InstallShield goes to identify what additional files are needed for each
> > > control.
> >
> > SWDEPEND.INI and ISDEPEND.INI are used during runtime to register files.
> > Express does not use any SWDEPEND.INI files from the windows directory.
> >
> > Ritesh
>
> Like Matt I am moving from the VB4 setupwiz to IS pro, I have tried the
> copy of IS supplied with VB4 and am now considering am upgrade to the
> Professional version.
>
> But have a number of Queries.
>
> 1. I use a number of third Party .OCX's, including one I build myself,
> which I would expect to be able to include in the auto. detect feature
> of ISPro is this possible and can you point me to where I might find
> this information.
>
> 2. I notice that IS Pro. does not support auto detect of .VBX files. The
> projects I am currently building make use of a number of third party
> .VBX's including ones I build myself. Would it be possible to include
> support auto detect of .VBX's.
>
> 3. I have noticed that a number of system files are incorrectly added,
> during auto detect, from <windir>\system32, these are 16 bit .dll's
> which only live in the <windir>\system directory. Is this a bug in the
> version which has now been fixed?
>
> 4. There does not seem to be any application support for maintaining the
> swdepend.ini and isdepend.ini files is this now supported in IS Pro?
>
> Thanks in advance for your help
> MartynI strongly recommend you avoid IS Pro 1.0. My use of this product has been a nightmare.
I have had many of the same experiences you've addressed. For example, I'd get a message
at runtime (after a supposedly successful install): "Can't load (or register) custom
control THREED16.OCX".

To fix this problem, I did the following:

1. Used QuickView to determine complete list of DLL's required by this OCX.
2. Ignored obvious DLLs like SHELL, KERNEL, etc and discovered that WIN87EM was required
but not in 16BITOLE list.
3. I modified both the SWDEPEND.INI and ISDEPEND.INI in the VB objects subdirectories
under the Installshield subdirectory, adding this entry for WIN87EM.DLL.
4. I copied the WIN87EM.DLL itself to this holding area called 16BITOLE (again under the
Installshield hierarchy of directories).
5. Then the "Automatic Review" button included this new dependency for me. (Automatic is
some joke...Ha! Ha!).
6. The auto review button wipes out some other items such as my checking of the ODBC
checkbox so I re-did that.
7. Finally, I get the thing to work. Sort of.

Actually, I'm about to get rid of Installshield Express Pro 1.0 and either upgrade to
1.1 or switch to another product (perhaps Wise ?). I still cannot get CRYSTL16.OCX to
register in all cases and the fact that the install does not log out these failures bugs
the hell out of me. I have spent hours and hours with different ramifications of errors
and issues with this stupid product with virtually no help from the vendor (are they
still not answering their support line phone ? I gave up calling long ago).

NewsArchive
09-18-1997, 12:00 AM
All:
!!All the following applies to the VB Objects in ISExpress 1.11a!!

I have done some digging myself and found the following:
As far as I can tell order is not important, but names and numbers are.
I have tested these through building disks, I haven't run any installs
yet.

I have a simple Addition for Sheridan DataWidgets 2.0b which is followed
a more complicated one for Crystal Reports Pro 5 (32bit).
- '...' denotes entries that were skipped for brevity.
*************************************************************************************************
*************************************************************************************************
SHERIDAN DATAWIDGETS 2.0b - BUILD 186
*************************************************
ISDEPEND.INI Entries:
*************************************************
[Options]
....
Option25=Sheridan DBGrid/Combo/DropDown ; Names to Appear in ISX
Option26=Sheridan Other DataControls
....
Sheridan DBGrid/Combo/DropDown=124 ; Unique Identifiers for Object
Sheridan Other DataControls=125

[GUIDS]
....
{D981334D-B212-11CE-AE8C-0000C0B99395}=Sheridan Other DataControls
;SSDATA Control - ClassIDs from VBP
{BC496AED-9B4E-11CE-A6D5-0000C0BE9395}=Sheridan DBGrid/Combo/DropDown
;SSDATB Control
....
;References Section
....
[Sheridan DBGrid/Combo/DropDown] ; Name to Match [Options] entry
Name=System Files - Sheridan DataWidgets ; Name of Group to create
Dest=<WINSYSDIR> ; Destination of Group
ReferTo1=SSDATB32 OCX ; Section of SWDEPEND.INI

[Sheridan Other DataControls]
Name=System Files - Sheridan DataWidgets
Dest=<WINSYSDIR>
ReferTo1=SSDATA32 OCX

*************************************************
SWDEPEND.INI Entries:
*************************************************
[SSDATA32 OCX]
Src=HKEY_CLASSES_ROOT\Sheridan.Data.Widgets\Version2\InstallDir\
Uses1=SSDATA32.OCX
Uses2=Data Widgets32 Support

[SSDATB32 OCX]
Src= HKEY_CLASSES_ROOT\Sheridan.Data.Widgets\Version2\InstallDir\
Uses1=SSDATB32.OCX
Uses2=Data Widgets32 Support

[Data Widgets32 Support]
Src=<WINSYSDIR>
Uses1=MFC42.DLL
Uses2=MSVCRT.DLL

[MFC42.DLL]
Register=$(DLLSelfRegister)

[MSVCRT.DLL]
Register=$(DLLSelfRegister)

*************************************************************************************************
*************************************************************************************************
CRYSTAL REPORTS PROFESSIONAL 5 32bit
*************************************************************************************************
ISDEPEND.INI (InstallShield DEPENDencies?):
*************************************************************************************************

[Options]
....
Option4=Crystal Report Control
....
Crystal Report ControlID=102
Crystal Report ControlID2=202 ; note the added reference -
numbers are arbitrary (as far as I can tell)
....
[GUIDS]
; This section is where you add ClassID references - obtainable from
; your VBP file opened in a text viewer (like QuickView or NOTEPAD).
....
; Reference Section - these refer to the SWDepend.ini sections
....
;##########################################################
;Crystal Reports Updated Installation

[Crystal Report Control]
Name=System Files - Crystal 5 ; Name of group in 'Groups and Files'
Dest=<WINSYSDIR> ; Destination Directory
ReferTo1=Crystal532 OCX ; Refers to section [Crystal532 OCX] in
swdepend.ini
Name2=Crystal 5 Support Files ;The '2' refers to the second entry
'ID' entry
Dest2=<WINDIR>\Crystal
ReferTo2=Crystal5 Support

*************************************************************************************************
SWDEPEND.INI (SoftWare DEPENDencies?):

[Crystal532 OCX]
Src=<WINSYSDIR>
Uses1=Crystal Common Files
Uses2=OCX Runtime Support
Uses3=MSVCRT20.DLL
Uses4=IMPLODE.DLL
Uses5=MFCANS32.DLL

[Crystal Common Files]
Src=<WINSYSDIR>
Uses1=CRYSTL32.OCX
Uses2=CRPE32.DLL
Uses3=Crystal DAO

[Crystal5 Support]
Src=<WINDIR>
SrcSub=Crystal
Uses1=u2ddisk.dll
Uses2=u2fdif.dll
Uses3= u2frec.dll
Uses4=u2fsepv.dll
Uses5=u2ftext.dll
Uses6=CRXLAT32.DLL