Windows Installer does not properly deploy policy files into the GAC

[Andy Elmhorst]

We have a number of different applications that share a common set of core
components. These components must be upgraded in-step so that all the
applications can continue to co-exist and share data.

To accomplish this, we are following the .Net guidelines. We are installing
our shared assemblies into the GAC. As our core components evolve, we rev
the version of the assemblies and install publisher policy files. It all
works great if we do it by hand.

Unfortunately, Windows Installer cannot be used to deploy these shared
components in this manner. Although Windows Installer will properly version
and upgrade assemblies elsewhere in the file system, it always installs our
newer version of our assemblies side-by-side in the GAC. I understand
side-by-side, and it's cool if that's what you want, but it is absolutely
not what we want. We want only the latest versions of our assemblies in the
GAC. Windows Installers appears to have no setting that will allow
assemblies to be deployed using publisher policy rather than side-by-side.
It ends up being a very ambigous and undocumented situation that concerns me
because our publisher policy files also get installed side-by-side, and I
have no idea how .Net knows which one to load for a particular application.

What is the Microsoft recommended practice for installing the latest version
of shared components with publisher policy using Windows Installer? Is this
a known issue with Windows Installer or is there a different way we should
be doing this?

Regards,

Andy

[David Barnard]

Oh, it's a known problem.... depending on whom you talk to a Microsoft, you
will get a different response - none particularly helpful.

The best option is to do it yourself, using the Fusion API. This gives you
complete control over the install and uninstall. You don't have to do the
hard part yourself - there is a good sample that shows how to do it:
Samples\Technologies\Interop\Advanced\comreg\fusioninstall.cs

You can easily wrap this up in a .NET installer class if you want.

If you need more detailed information, this link may help:
http://support.microsoft.com/?id=317540

David

"Andy Elmhorst" <msdnn...@elmhorst.com> wrote in message
news:uXR0Wxa...@TK2MSFTNGP10.phx.gbl...

[Adam Semel]

Hey Andy,

We leave the older assemblies behind by design. We want to insure that
other applications don't get broken by the upgrade of your newer assembles.
What you want to is actually a small update or patch of your assemblies in
the GAC. For more information on small updates or patching see the help
topic Creating a Small Update Patch in the Windows Installer help file.

You can download and install the windows installer help file from
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/.

Adam Semel
Windows Installer Team
Microsoft Developer Support

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.

[Phil Wilson]

Bit of a whine: What bugs me about that approach is that the author of the MSI package should be
able to make that choice depending on whether the incoming assembly has the same Windows installer
component guid as the one already there. If you want to replace it in the GAC, use the same guid, if
you want side-by-side give it a new guid. Other applications using the assembly aren't broken
because the installer is reference counting by component guid, so in practice, any clients sharing
the assembly are not broken, and in fact the problem with forcing behavior using gacutil (or the
fusion API) is that it's not aware of installer component sharing and breaks installer sharing. The
current behavior is causing a lot of grief. Other related issues are that you can't use an
incremented File version to replace an assembly in the GAC with the same assemblyversion, and major
upgrades don't appear to be replacing assemblies in the GAC either.
--
Phil Wilson [MVP Windows Installer]
----
"Adam Semel" <ase...@online.microsoft.com> wrote in message
news:PGL2AXbO...@cpmsftngxa06.phx.gbl...

[Andy Elmhorst]

THIS CANNOT BE BY DESIGN :-). It is a bug. It is impossible to properly
deploy assemblies using publisher policy if Windows Installer will not
remove previous versions. As an installer engineer, it is my responsibility
to ensure that I do not break previous versions of my application, not that
of Windows Installer. In this case Windows Installer's behaviour is not
keeping previous version of my application from breaking, it is CAUSING THEM
TO BREAK.

Using a patch is not a solution that will work. We need publisher policy to
work whether we are doing a minor or a major version release. Can somebody
at Microsoft please acknowledge that this is a problem? Phil Wilson has a
good grasp of what the problem is and has verified that what I am saying is
true, as well as given more details in his posted reply to this question.

For now, what I am attempting is to use the Fusion API myself, which from my
testing appears like it will work. I would just like to know if Microsoft is
acknowledging this as a problem and is planning to fix it in some future
release.

Regards,

Andy Elmhorst
Software Engineer
Renaissance Learning.

"Adam Semel" <ase...@online.microsoft.com> wrote in message
news:PGL2AXbO...@cpmsftngxa06.phx.gbl...