"Keith DuPont" <KeithDuPont@discussions.microsoft.com> wrote in message
news:3EF0E6AF-25C5-4BE0-A357-D7DF30C1A2F6@microsoft.com...
>I am attempting to delete some files from my target installation folder
>prior
> to new versions of the files being copied over during the installation.
> In
> an effort to implement this functionality I created a custom installer
> class
> that I've added to my solution. I would like specific actions in this
> custom
> installer class to run before files are copied to the target installation
> folders.
>
> I have performed the following steps:
> 1) Overridden the install method in the custom installer class
> 2) Within the overridden install method I call another method to perform
> my
> specific action (delete older versions of a file). This call happens
> before
> the call to MyBase.Install.
> 3) I have added my custom install dll as a custom action to the "Install"
> custom action folder.
>
> The problem is that my delete file method gets called after the new files
> have been copied to the target installation directory.
>
> I then attempted to add a BeforeInstall event to the custom installer
> class
> that would call my delete files method in an effort to grab control before
> the base install event is processed. Unfortunately this event did not get
> fired until after the new files were copied to the target installation
> folder.
>
> I have two questions:
> 1) Is it possible to get control via a custom installer class (or another
> methodology) prior to the new files being copied over?
>
> 2) Shouldn't the before install event that handles MyBase.BeforeInstall be
> called prior to files being copied (or other install actions)?
>
> Thank You in advance,
>
> Regards,
> Keith D.
>

"Phil Wilson" wrote:

> In answer to your questions:
>
> 1) No, not with Visual Studio setups because that's where the install custom
> actions are sequenced - nearly at the end of the installation.
>
> 2) No. "Before Install" doesn't mean "before the install". It means "before
> the code in the Install custom action".
>
> Why are you deleting older versions of files? If they are literally
> versioned code files they'll be replaced anyway with higher versions. Are
> they data files?
>
> --
> Phil Wilson
> [Microsoft MVP-Windows Installer]
>
> "Keith DuPont" <KeithDuPont@discussions.microsoft.com> wrote in message
> news:3EF0E6AF-25C5-4BE0-A357-D7DF30C1A2F6@microsoft.com...
> >I am attempting to delete some files from my target installation folder
> >prior
> > to new versions of the files being copied over during the installation.
> > In
> > an effort to implement this functionality I created a custom installer
> > class
> > that I've added to my solution. I would like specific actions in this
> > custom
> > installer class to run before files are copied to the target installation
> > folders.
> >
> > I have performed the following steps:
> > 1) Overridden the install method in the custom installer class
> > 2) Within the overridden install method I call another method to perform
> > my
> > specific action (delete older versions of a file). This call happens
> > before
> > the call to MyBase.Install.
> > 3) I have added my custom install dll as a custom action to the "Install"
> > custom action folder.
> >
> > The problem is that my delete file method gets called after the new files
> > have been copied to the target installation directory.
> >
> > I then attempted to add a BeforeInstall event to the custom installer
> > class
> > that would call my delete files method in an effort to grab control before
> > the base install event is processed. Unfortunately this event did not get
> > fired until after the new files were copied to the target installation
> > folder.
> >
> > I have two questions:
> > 1) Is it possible to get control via a custom installer class (or another
> > methodology) prior to the new files being copied over?
> >
> > 2) Shouldn't the before install event that handles MyBase.BeforeInstall be
> > called prior to files being copied (or other install actions)?
> >
> > Thank You in advance,
> >
> > Regards,
> > Keith D.
> >
>
>