GAC and installer component versioning

  • Thread starter Thread starter EP
  • Start date Start date
E

EP

I have a question regarding Windows Installer components and the GAC.

I have assembly MyAssembly.v1.0.0.0 that is contained in a merge module.
For the next release of that component, I

1) update the file in the component, keeping the same component code, but
the dll is now version 1.0.1.0
2) increment the merge module version.
3) include a publisher policy for that component.

Is this the correct way to go about this? I'm a bit confused since when you
reversion a file that is installed to the same location, you are supposed to
keep the same component code. But, GAC files actually go in different file
locations, even though their TARGET is the GlobalAssemblyCache.

So, should a new version of a GAC asssembly change it's component code?
 
The side-by-side rules in the GAC win over the MSI component idea - the new
assembly version will mean you'll get both assemblies in the GAC, new and
old. I don't think two assemblies in the GAC with the same installer
component Guid is a good thing, so change that component Guid.
 
Only if your product needs both versions of the assembly you should change
the component ID. In this case both, the old version with the old component
ID and the new version with the new ID should be included in your setup.
Otherwise chaning the component ID has the effect that you cannot create a
small or minor update/patch since you are essentially removing the component
with the old ID from the package.

However I guess that typically your application will only need the new
version of the assembly and no longer need the old version. In this case it
is recommended to change the strong name of the updated assembly, but retain
the same Windows Installer ComponentID when packaging the assembly into the
updated MSI.

--
Stefan Krueger
Microsoft Windows Installer MVP

Please post your questions in the newsgroup or vist one of these web sites:

Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de

InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)


Phil Wilson said:
The side-by-side rules in the GAC win over the MSI component idea - the
new assembly version will mean you'll get both assemblies in the GAC, new
and old. I don't think two assemblies in the GAC with the same installer
component Guid is a good thing, so change that component Guid.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760

EP said:
I have a question regarding Windows Installer components and the GAC.

I have assembly MyAssembly.v1.0.0.0 that is contained in a merge module.
For the next release of that component, I

1) update the file in the component, keeping the same component code, but
the dll is now version 1.0.1.0
2) increment the merge module version.
3) include a publisher policy for that component.

Is this the correct way to go about this? I'm a bit confused since when
you
reversion a file that is installed to the same location, you are supposed
to
keep the same component code. But, GAC files actually go in different
file
locations, even though their TARGET is the GlobalAssemblyCache.

So, should a new version of a GAC asssembly change it's component code?
Click to expand...
Click to expand...
 
I found the official answer to the questions:
http://msdn.microsoft.com/library/en-us/msi/setup/updating_assemblies.asp

--
Stefan Krueger
Microsoft Windows Installer MVP

Please post your questions in the newsgroup or vist one of these web sites:

Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de

InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)


Stefan Krueger said:
Only if your product needs both versions of the assembly you should change
the component ID. In this case both, the old version with the old
component ID and the new version with the new ID should be included in
your setup. Otherwise chaning the component ID has the effect that you
cannot create a small or minor update/patch since you are essentially
removing the component with the old ID from the package.

However I guess that typically your application will only need the new
version of the assembly and no longer need the old version. In this case
it is recommended to change the strong name of the updated assembly, but
retain the same Windows Installer ComponentID when packaging the assembly
into the updated MSI.

--
Stefan Krueger
Microsoft Windows Installer MVP

Please post your questions in the newsgroup or vist one of these web
sites:

Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de

InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)


Phil Wilson said:
The side-by-side rules in the GAC win over the MSI component idea - the
new assembly version will mean you'll get both assemblies in the GAC, new
and old. I don't think two assemblies in the GAC with the same installer
component Guid is a good thing, so change that component Guid.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760

EP said:
I have a question regarding Windows Installer components and the GAC.

I have assembly MyAssembly.v1.0.0.0 that is contained in a merge module.
For the next release of that component, I

1) update the file in the component, keeping the same component code,
but
the dll is now version 1.0.1.0
2) increment the merge module version.
3) include a publisher policy for that component.

Is this the correct way to go about this? I'm a bit confused since when
you
reversion a file that is installed to the same location, you are
supposed to
keep the same component code. But, GAC files actually go in different
file
locations, even though their TARGET is the GlobalAssemblyCache.

So, should a new version of a GAC asssembly change it's component code?
Click to expand...
Click to expand...
Click to expand...
 
Back
Top