Upgrade fails to register assemblies into the GAC.

I've recently been tasked with figuring out why the msi's that my new company
creates can't be set to do automatic upgrades. The old versions must be
manually uninstalled befrore running the new msi's or an error occurs. What
I believe happens is the msi does costinitalize first and determines the
assemblies are already on the machine (from the old install) and doesn't mark
them for reinstall. Then when RemoveExistingProduct runs, it takes those
assemplies out of the GAC. This leaves the assemblies out of the GAC until
you run the application which sees they are missing and does a repair. The
complexity comes from a second msi which may or may not need to be ran at the
same time. That msi has a custom action which references the missing
assembly, causing it to blow up. The key piece of information here that
causes this to happen is the assemblies are NOT versioned on each build of
the msi. Current protocols require that the assemblies not have their
version changed. Only the msi is versioned. The only solution I've found is
to move the execution order of RemoveExistingProduct to before
CostInitialize, but this puts it out of the audit loop and a rollback won't
put the old version back.

Any suggestions on a better solution for this problem (other than starting
to version the assemblies).

Is it this?

http://support.microsoft.com/kb/905238

There may be a solution in Windows 7, but I have't tested it.

--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972


"Jason Sachan" <Jason Sachan@discussions.microsoft.com> wrote in message
news:47FC3AE7-3C61-4584-8AAD-CBFC1BB8458D@microsoft.com...
> I've recently been tasked with figuring out why the msi's that my new
> company
> creates can't be set to do automatic upgrades. The old versions must be
> manually uninstalled befrore running the new msi's or an error occurs.
> What
> I believe happens is the msi does costinitalize first and determines the
> assemblies are already on the machine (from the old install) and doesn't
> mark
> them for reinstall. Then when RemoveExistingProduct runs, it takes those
> assemplies out of the GAC. This leaves the assemblies out of the GAC
> until
> you run the application which sees they are missing and does a repair.
> The
> complexity comes from a second msi which may or may not need to be ran at
> the
> same time. That msi has a custom action which references the missing
> assembly, causing it to blow up. The key piece of information here that
> causes this to happen is the assemblies are NOT versioned on each build of
> the msi. Current protocols require that the assemblies not have their
> version changed. Only the msi is versioned. The only solution I've found
> is
> to move the execution order of RemoveExistingProduct to before
> CostInitialize, but this puts it out of the audit loop and a rollback
> won't
> put the old version back.
>
> Any suggestions on a better solution for this problem (other than starting
> to version the assemblies).

That is the decription of the problem, but neither workaround will help. I
can't change the assembly version right now, so option 1 isn't an option. As
for option 2, this does keep the assembly in the GAC, but it doesn't update
it with the version in the new msi. As described, it leaves the original in
place. In my situation, the Assembly may have changed and needs to be
replaced even though the version hasn't been changed.

"Wilson, Phil" wrote:

> Is it this?
>
> http://support.microsoft.com/kb/905238
>
> There may be a solution in Windows 7, but I have't tested it.
>
> --
> Phil Wilson
> The Definitive Guide to Windows Installer
> http://www.apress.com/book/view/1590592972
>
>
> "Jason Sachan" <Jason Sachan@discussions.microsoft.com> wrote in message
> news:47FC3AE7-3C61-4584-8AAD-CBFC1BB8458D@microsoft.com...
> > I've recently been tasked with figuring out why the msi's that my new
> > company
> > creates can't be set to do automatic upgrades. The old versions must be
> > manually uninstalled befrore running the new msi's or an error occurs.
> > What
> > I believe happens is the msi does costinitalize first and determines the
> > assemblies are already on the machine (from the old install) and doesn't
> > mark
> > them for reinstall. Then when RemoveExistingProduct runs, it takes those
> > assemplies out of the GAC. This leaves the assemblies out of the GAC
> > until
> > you run the application which sees they are missing and does a repair.
> > The
> > complexity comes from a second msi which may or may not need to be ran at
> > the
> > same time. That msi has a custom action which references the missing
> > assembly, causing it to blow up. The key piece of information here that
> > causes this to happen is the assemblies are NOT versioned on each build of
> > the msi. Current protocols require that the assemblies not have their
> > version changed. Only the msi is versioned. The only solution I've found
> > is
> > to move the execution order of RemoveExistingProduct to before
> > CostInitialize, but this puts it out of the audit loop and a rollback
> > won't
> > put the old version back.
> >
> > Any suggestions on a better solution for this problem (other than starting
> > to version the assemblies).
>

one of your files is marked as hidden


"Jason Sachan" <Jason Sachan@discussions.microsoft.com> wrote in message
news:47FC3AE7-3C61-4584-8AAD-CBFC1BB8458D@microsoft.com...
> I've recently been tasked with figuring out why the msi's that my new
> company
> creates can't be set to do automatic upgrades. The old versions must be
> manually uninstalled befrore running the new msi's or an error occurs.
> What
> I believe happens is the msi does costinitalize first and determines the
> assemblies are already on the machine (from the old install) and doesn't
> mark
> them for reinstall. Then when RemoveExistingProduct runs, it takes those
> assemplies out of the GAC. This leaves the assemblies out of the GAC
> until
> you run the application which sees they are missing and does a repair.
> The
> complexity comes from a second msi which may or may not need to be ran at
> the
> same time. That msi has a custom action which references the missing
> assembly, causing it to blow up. The key piece of information here that
> causes this to happen is the assemblies are NOT versioned on each build of
> the msi. Current protocols require that the assemblies not have their
> version changed. Only the msi is versioned. The only solution I've found
> is
> to move the execution order of RemoveExistingProduct to before
> CostInitialize, but this puts it out of the audit loop and a rollback
> won't
> put the old version back.
>
> Any suggestions on a better solution for this problem (other than starting
> to version the assemblies).