none
2 different versions of an Outlook Addin co-exist on a machine when deployed through SCCM RRS feed

  • Question

  • The installation location of the Addin is AppData/Roaming for per user and EXE builds and Program Files for per machine build. The per machine build works fine on SCCM. The per user install makes 2 versions to co-exist in the same machine. Is this problem is really because of installation location or am I missing something?

    Thanks in advance.


    Thanks Prasad

    Tuesday, January 27, 2015 5:06 AM

Answers

  • You need to keep the Product code unchanged.

    The Changing the Product Code page in MSDN states the following:

    An update that meets the following guidelines generally does not require a change of the product code and can be handled as a small update, or if the version is to change, as a minor upgrade:

    • The update can enlarge or reduce the feature-component tree but it must not reorganize the existing hierarchy of features and components described by theFeature and FeatureComponents tables. It can add a new feature to the existing feature-component tree. If it removes a parent feature, it must also remove all the child features of the removed feature.
    • The update can add a new component to a new or an existing feature.
    • The update must not change the component code of any component. Consequently, a small update or minor upgrade must never change the name of a component's key file because this would require changing the component code.
    • The update must not change the name of the .msi file of the installation package. Instead, because it modifies the package, it should change the package code. Note that this means that the update can change the tables, custom actions, and dialogs in the .msi file without changing the file's name.
    • The update can add, remove, or modify the files, registry keys, or shortcuts of components that are not shared by two or more features. If the update modifies a versioned file, that file's version must be incremented in the File table. If the update removes resources, it should also update the RemoveFile andRemoveRegistry tables to remove any unused files, registry keys, or shortcuts that have already been installed.
    • The update of a component that is shared by two or more features must be backward compatible with all applications and features that use the component. The update can modify the resource of a shared component, such as files, registry entries, and shortcuts, as long as the changes are backward compatible. It is not recommended that the update add or remove files, registry entries, or shortcuts from a shared component.
    • A small update is shipped as a Windows Installer patch package. (A full product CD-ROM is usually not provided with a small update.)

    The product code must be changed if any of the following are true for the update:

    • Coexisting installations of both original and updated products on the same system must be possible.
    • The name of the .msi file has been changed.
    • The component code of an existing component has changed.
    • A component is removed from an existing feature.
    • An existing feature has been made into a child of an existing feature.
    • An existing child feature has been removed from its parent feature.

    • Marked as answer by Prasad U S Wednesday, January 28, 2015 3:19 PM
    Wednesday, January 28, 2015 2:37 PM

All replies

  • Hello Prasad,

    Why do you need to install two versions of the add-in on the PС?

    It looks like you need to keep the product ID unchanged to prevent multiple installation of the same software.

    Tuesday, January 27, 2015 6:42 PM
  • Hi Eugene,

    Thanks for the reply.

    My scenario is when I try to upgrade an existing version of Addin from SCCM. For normal installations (without SCCM), it works well. But only when I push my Addin through SCCM, I am running into this trouble. Instead of upgrading the Addin, both lower and higher versions co-exist.


    Thanks Prasad

    Wednesday, January 28, 2015 4:28 AM
  • Most probably you change the product ID in the installer with each build, so SCCM can't detect the previously installed version of the product.
    Wednesday, January 28, 2015 10:50 AM
  • Yes Eugene. Product Code is changed each time. But always upgrade code remains same and the product code should change for new versions right? Correct me if I am wrong.

     

    Thanks Prasad

    Wednesday, January 28, 2015 12:19 PM
  • You need to keep the Product code unchanged.

    The Changing the Product Code page in MSDN states the following:

    An update that meets the following guidelines generally does not require a change of the product code and can be handled as a small update, or if the version is to change, as a minor upgrade:

    • The update can enlarge or reduce the feature-component tree but it must not reorganize the existing hierarchy of features and components described by theFeature and FeatureComponents tables. It can add a new feature to the existing feature-component tree. If it removes a parent feature, it must also remove all the child features of the removed feature.
    • The update can add a new component to a new or an existing feature.
    • The update must not change the component code of any component. Consequently, a small update or minor upgrade must never change the name of a component's key file because this would require changing the component code.
    • The update must not change the name of the .msi file of the installation package. Instead, because it modifies the package, it should change the package code. Note that this means that the update can change the tables, custom actions, and dialogs in the .msi file without changing the file's name.
    • The update can add, remove, or modify the files, registry keys, or shortcuts of components that are not shared by two or more features. If the update modifies a versioned file, that file's version must be incremented in the File table. If the update removes resources, it should also update the RemoveFile andRemoveRegistry tables to remove any unused files, registry keys, or shortcuts that have already been installed.
    • The update of a component that is shared by two or more features must be backward compatible with all applications and features that use the component. The update can modify the resource of a shared component, such as files, registry entries, and shortcuts, as long as the changes are backward compatible. It is not recommended that the update add or remove files, registry entries, or shortcuts from a shared component.
    • A small update is shipped as a Windows Installer patch package. (A full product CD-ROM is usually not provided with a small update.)

    The product code must be changed if any of the following are true for the update:

    • Coexisting installations of both original and updated products on the same system must be possible.
    • The name of the .msi file has been changed.
    • The component code of an existing component has changed.
    • A component is removed from an existing feature.
    • An existing feature has been made into a child of an existing feature.
    • An existing child feature has been removed from its parent feature.

    • Marked as answer by Prasad U S Wednesday, January 28, 2015 3:19 PM
    Wednesday, January 28, 2015 2:37 PM
  • Thank you Eugene.

    Thanks Prasad

    Wednesday, January 28, 2015 3:20 PM