We have written a .NET add-in for MS Excel 2010. it is working fine, and we are using the MS deployment package to create an MSI which installs the add-in just fine.
Problem is that sometimes we need to install two versions of the add-in. Perhaps one is todays version, and one is the next version being tested.
What all would I need to update and where to allow the installation of the add-in mroe than once, on the same machine?
To begin with, tried changing the GUIDAttribute, of both the versions of the Add-in project:
<GuidAttribute("75AC751D-AB16-4E37-8940-XXXXXXXXX"), ProgIdAttribute("MyAddin.connect")>
With that change, i think i would need to change the productcode,packagecode and upgradecode in the setup.
Is my understanding correct that if I need to install add-on of my two environments (UAT, Prod) on the same machine, then my productcode, packagecode and upgradecode need to be all unique.
In case later, the user get a new version of the prod add-in, then that add-in should have the same upgradecode, and packagecode, but different productcode only (specific
Can i keep the same ProgIDAttribute for both UAT and Prod in this scenario?
Correct, you should change all 5 of them (and this is enough).
The ProgIDAttribute and GuidAttribute are used to register the addin for the Excel (as name of a key in registery; therefore they both must be changed)
The PackageCode, UpgradeCode, and ProductCode will allow you to install two packages on the same computer. You cannot keep package code (because ALL packages at all should have different package codes). You can't keep product code, because if you do then the second package will reject to install saying you have another version of the same product installed.
So, in the addin project:
ProgID
Guid (i.e. ClassID)
In the installer project
ProductCode
PackageCode
UpgradeCode
If user gets a new build, to allow upgrade, you should change ProductVersion, ProductCode, and PackageCode, but keep UpgradeCode in the installer project (old installation is identified by the UpgradeCode).
Related
I've got an application which I have installed alongside a newer version with a different AppVersion, but identical AppId. If I check the control panel, I noticed installing two versions alsongside erases the older uninstaller entry in the Control Panel uninstall list. Why does InnoSetup do this? This forces the user to have to manually determine the uninstaller for the other application.
That's as designed. The AppId identifies the software. You are not supposed to install another copy of an application with the same AppId to a different folder. If you use the same folder, the uninstaller of the latest installation would take care of all installed versions.
See https://jrsoftware.org/ishelp/index.php?topic=sameappnotes
If you want to allow parallel installations of different versions, you have to have the AppId unique per version.
Note that the entry in the uninstall list is not erased, it is overwritten, as the AppId is the key for the list.
I'm developing an office-js addin for corporate client which insists on using legacy versions of Excel (1708 or 1808).
But when I install excel from office 365, I get version 1906.
In the old days, with software, there were installers you could find in a directory that had version stamps on them, and you could create a VM, and just install the version you wanted. But the fancier installers appear to download stuff automatically and always (at least default to) the latest versions.
How do I install a legacy version of Excel on a VM for testing?
There's no special process for getting an earlier version when you are testing add-ins. It should be the same process as an end user would use. Please try the steps at this article: Revert to an earlier version of Office. I think you can find the build numbers that you will need either from your customer or from this page: Update history of Office 365.
I am trying to migrate from InstallShield to Inno Setup. I have all setup but I got stuck on a single case when the user might downgrade from Inno Setup back to the InstallShield. I need InstallShield to fail the installation or at least warn the user to uninstall Inno Setup version first manually (otherwise I get two versions installed and things get messed up).
I CAN´T of course change the existing InstallShield installers in any way since they have already been released. Solution must come from Inno Setup. Any ideas how this could be done? I understand this might me impossible.
A stock InstallShield template automatically authors a prevent downgrade rule into the MSI. Assuming your InnoSetup project was created using the same UpgradeCode as the InstallShield project this should work automatically.
If you gave your new InnoSetup project a new UpgradeCode GUID and authored a remove legacy product type rule using the old GUI in the Upgrade table there really isn't much InstallShield could possibly do. That's the nature of installers... once it's shipped it's shipped.
I do not think this can be done. The Inno Setup does not use the Windows Installer, so the InstallShield won't even know that your product is already installed. And Inno Setup uninstaller cannot know that the InstallShield installer is starting.
The best what you can do is to have your Inno Setup installer remove the InstallShield installation and install itself to another folder. So when you re-install the InstallShield installation, it at least won't conflict/break the Inno Setup installation. And user will be able to correctly uninstall the new Inno Setup installation, if needed.
OK I solved it. (kind of)
There is a simple trick what you can do to trick the InstallShield to think it is already installed even if it is not.
First you need to locate all the registry entries with your UpgradeCode and ProductCode (it should be 3 entries for the UC and 5 for the PC) normally created by the InstallShield. Also note that both GUIDS are stored in the registry in reversed form (first 8 chars are backwards!!! - rest I am not sure of but it can be googled).
Now you need to make the InnoSetup recreate this registry entries. When InstallShield starts it looks for existing version in the registry, if it finds one it tries to uninstall it using the copy of the original installer - path to the copy is stored in the registry at
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products{reversed guid of product code}\InstallProperties]
"LocalPackage"="C:\Windows\Installer\[random string].msi"
If InstallShield wont find this file it will fail. You can also create your own MSI file which will call the uninstall.exe file from InnoSetup.
I have a MSI installer that installs an Excel plugin. I'd like to know if Excel is installed and not install the plugin if its missing. MsiEnumProducts gives a list of installed products except Microsoft Office. WTF? Is there a better way to do this?
I'd like my MSI installer UI to display or not a checkbox to install Excel component if we have Excel.
Puzzled,
Gerry
Excel is a feature within one of many Office products. Just because Office is installed doesn't mean that Excel is installed. It also doesn't mean the version of Excel that you need is installed.
I would instead check certain registry key/values based on your exact needs.
I'm setting up a Windows installer for a new software product using InnoSetup. The tool completes engineering calculations and future versions will contain improved algorithms or functionality. Most users will want to keep the old version even when they install a new version so they can reproduce results for old projects.
Can I make InnoSetup install a new version alongside the old version?
I've tried putting the software version number in the default directory name:
DefaultDirName={pf}\{#PRODUCT_NAME} {#PRODUCT_VERSION_LONG}
and forcing folder selection:
DisableDirPage=yes
The first installation works fine, but when the installer is run for a later version, it sees the first version is installed and pulls in the first version folder name as the default location - so version 0.2 installs in the " 0.1" folder.
The only workaround I can think of is to generate a new AppId for each version - effectively making every version a new software product. Is there a better way?