Re: Package and Deployment Questions
From: Robert Suffecool (rmsuffy_at_hotmail.com)
Date: 08/17/04
- Next message: Robert Suffecool: "Re: Package and Deployment Questions"
- Previous message: Rick Rothstein: "Re: remove duplicate items from array"
- Maybe in reply to: Robert Suffecool: "Package and Deployment Questions"
- Next in thread: Robert Suffecool: "Re: Package and Deployment Questions"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 16 Aug 2004 21:19:56 -0700
Damn Ralph... creating a "home deployment package" is starting to sound like
it is going to take more effort than writing the program code I want to
install! Holy-Toledo! Thanks for the thoughts though. Are the other
deployment wizards you spoke of expensive -- ie, Wise?
Robert
"Ralph" <nt_consulting32@hotmail.com> wrote in message
news:uhypVUkgEHA.1344@TK2MSFTNGP11.phx.gbl...
>
> "Robert Suffecool" <rmsuffy@hotmail.com> wrote in message
> news:ucScXpigEHA.1048@tk2msftngp13.phx.gbl...
> > Ralph stated... <snip>
> > > >
> < snipped>
> >
> > What makes the MDAC different from other system files if you don't have
to
> > have to include system files? Why couldn't I assume it was already
> > installed during the O/S install or another program package installing
it?
> >
> > Robert
> >
>
> I probably led you astray and was a little too flippant. "System files"
> refers to files that are specific to a particular platform but can also
> contain files that come with specific packages, such as the VB Runtime and
C
> runtime files. Exactly whether or not you should include these files
depends
> on your target, and the specific platform.
>
> If you are installing to a home machine (*note below) that you feel is
> likely not to have any of the files, then go ahead and include them in
your
> install. For a corporate box that has already had 50+ installs - leaving
the
> VB Runtime out of the install is a good idea. Most of the latest platforms
> already have the C runtime and MFC dlls.
>
> Usually (always a risky assumption) whatever version a platform might have
> is best for that platform - and you run a risk substituting yours for
> theirs - breaking something in the process. Complicating this scenario is
> that often the component you are actually using on your development box
> (that gets 'compiled' in) is NOT the component that will be included in
the
> package, because the components actually included are the ones in the
> PDWizard\redist folder. (Maybe) To be sure from where you will pickup for
> packaging any specific component take a look at the vb6dep.ini file in the
> PDWizard\ folder.
>
> If you are including any of these files - make sure this folder is
updated.
> No M$ SP or install updates these files from the original VB setup. You
have
> to do it manually.
>
> Also due the the higher security profiles of many machines - installing
> 'system files' will often require an administrator. Usually something to
be
> avoided if possible.
>
> So this is a long round-about way of saying if you can avoid installing
> "system files' do so. COM can get complicated enough without setting up a
> scenario for failure.
>
> The MDAC is different in that there are so many different versions. M$
uses
> the same name for all versions. Unfortunately they are not all created
> equally. Earlier mdacs contained Jet for example. Newer versions don't.
Also
> the MDAC is usually installed as a part of M$ office applications. It
didn't
> necessary come with the platform itself.
>
> You can install multple versions and they form a "Data Provider Stack" -
> ie., ADO 2.5 can exists a long side 2.8 etc. (They share updated files and
> some different files - most have multiple interfaces). If you are using
2.8
> in your application and you install on a 3 yr-old Win2k - it likely may
only
> have 2.5/2.6 or no MDAC at all. There is no harm done including the mdac
you
> used to compile your application - and there is a greater likelihood the
> target platform will not have the required version.
>
> Now one more "gotcha" - even if you compile your program with ADO 2.8, if
> you don't replace the mdac_typ.exe file in the PDWizard\Redist folder -
> guess what? - you will install 2.5. Always update the mdac_typ.exe file in
> this folder with the mdac version you are using.
>
> You can begin to see why Inno and WMI are perhaps better solutions? <g>
>
> * Home computers - if you are attempting to create a complex shrink-wrap
> install I heartily suggest you investigate using Wise or one of the other
> industrial-strength installers.
>
> hope this rambling got close to answering your question.
>
> -ralph
>
>
- Next message: Robert Suffecool: "Re: Package and Deployment Questions"
- Previous message: Rick Rothstein: "Re: remove duplicate items from array"
- Maybe in reply to: Robert Suffecool: "Package and Deployment Questions"
- Next in thread: Robert Suffecool: "Re: Package and Deployment Questions"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
