coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

MSI Rules:

You can always have many different Assemblies, with different versions in an MSI.

CoApp Rules:

All Assemblies in the same MSI must share the same version. If you need assemblies with different versions, you need two MSIs.

G

From: Eric Schultz [mailto:wwahammy@xxxxxxxxx]
Sent: Thursday, August 12, 2010 7:01 PM
To: Garrett Serack
Cc: Trevor Dennis; coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Questions, Questions, Questions

That what I thought but I'm a little confused. If we use CO_BINDING_POLICY to specify which versions this package replaces for SxS purposes, then does that mean there's a single SxS assembly for a package? If not, then does every SxS assembly/binary in the package have exactly the same version numbers?

I think this is why no one uses SxS assemblies, man they're confusing! :)

On Thu, Aug 12, 2010 at 8:48 PM, Garrett Serack <garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>> wrote:

Yeah... components in MSI are more fine grained than you think. An install is almost always made up of many components.



G



Eric Schultz <wwahammy@xxxxxxxxx<mailto:wwahammy@xxxxxxxxx>> wrote:


My thoughts on ProductCode are just create another 'HUID' but append the word "product" to the name, version, architecture and public key token before hashing. That way every time they build the same package, the ProductCode is also the same.

Not really sure how to do for the Guid attribute for each Component offhand though. Do we expect there to be more than one component in each MSI?

Eric
On Thu, Aug 12, 2010 at 8:06 PM, Trevor Dennis <trevor@xxxxxxxxxxxxx<mailto:trevor@xxxxxxxxxxxxx>> wrote:
ackageCode must be unique on every new MSI update.  They could include the version, or simply be a real GUID.