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 <garre...@microsoft.com>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 <wwaha...@gmail.com> 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 <tre...@dennis-it.com>wrote: > >> ackageCode must be unique on every new MSI update. They could include the >> version, or simply be a real GUID. >> > >
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
