6 replies to this topic

[Dave I]

Simple enough question.  I have  a component with one file Test.dll (1,0,0,1) and I want to replace this with another version of the file with increased functionality.  Test (1,1,0,1) Now do I need to change the component code MSI states :

"A NEW VERSION of a component is assigned the same component code as another existing component. Modifying a component without changing the component code is only optional in the following cases:  

1.The changes to the component been proven by testing to be BACKWARD COMPATIBLE with all previous versions of the component.

Firstly I am shipping the new version of a file, not the new version of a component is that what it means (components have no version number.)

Secondly, why does the file need to be backwardly compatible with the file that its replacing?  Surely it doesnt matter if its being replaced.

If I have to change the Component Code, I need to change the Product Code, and if I need to change the ProductCode then it becomes a Major Upgrade.  

Help Please,
Dave.

[Dave I]

Furthermore...

MSI - "Never create two components that install a resource under the same name and target location. "

So, if I want to replace a file during an upgrade I should keep the same component code.

I'm getting a bit confused with all the rules!!!!!!

[pdriley]

No, don't change the component code.

It's only necessary to do so if you need to install to a different location and retain the original.

Say, for example, a component is commonly installed to Windows\System and you want to install a new version of that component in the App directory.

If you leave the component code the same in that case, WI will see that one already exists in Windows\System, and it will upgrade it instead of producing more copies.

Hence the part about backwards compatibility... if it is backwards compatible then you're not going to break someone else's program by upgrading it.  If it isn't then you are going to cause some serious damage.

It's all about the philosophy of removing DLL ####: hundreds of different versions of the same DLL on one system all trying to be loaded at once.

[Ian Blake]

Your first e-mail is saying a component that does something different should not have the same component code.  For instance I am currently writing a plug and play driver to replace a legacy driver.  This is completely incompatible with earlier interface components so it will have a new guid even though it fulfils the same function.  (it also has a different name).  The eventual function of the new component is identical to the old component but it work in a different and incompatible way to the old component.

Presumably your test.dll does  the same job with fewer bugs and extra functions but is basically the same item.  In thjs case the GUID should stay the same as should the file name.

Your second article is a statement of common sense.  Do not have two different objects that you can not tell apart.  This will lead to all kinds of complications.  For example a major upgrade will not install the new component if the keyfile has a higher version.  Then it would remove it when it removes the old component, which is no longer required, is removed.

[Dave I]

Ok, thanks for that Paul, things are "Slowly" falling into place.

The next million dollar question is that I need to automate our patch mechanism....  Say, our product has 50 components and I only want to upgrade 2 of those components.  Would I be right in saying I need to create a new  .ism with the same feature heirachy as the original and give the two components in the patch the same component codes as the orginals.  

This doesnt seem too bad for 2 components but what do I do when I need to replace 20-30 components and give them the same component codes as the originals?  Is there any patch automation interface or command line parameters.

Your help would be much, much appreciated.

[pdriley]

Dave,

There isn't specifically a patch interface but I think you could use a combination of the Windows Installer Automation interface (bearing in mind that an ISM file is just an extended MSI / MSM / MSP file) and the ISWi Automation interface.

I'm not even going to try to explain how, you'll want to read as much documentation as you can, but I'm sure there's a way. :))

[Stefan Krueger]

Why not build your new project from the existing project file?
.ism is an extended .msi with Developer. It is not with IPWI 2.03 for instance.