For reference, I am using InstallShield 2015 and the project is a Basic MSI.
I know the uninstaller is created automatically, what I do not like about it is how I'm always shown the "Do you want to allow the following program from an unknown publisher to make changes to this computer?" warning.
Is there a way to sign the uninstaller the same way I do with the program itself so that users don't need to see this warning?
Assuming Basic MSI and Windows 7, I don't know why you'd get this message.
In Windows NT/2K/XP/Vista, MSI stripped the storage out of an MSI and stored it in c:\windows\installer. This was for space considerations and it would resolve the full MSI if content was needed.
In Vista they added UAC and the complaint was uninstall would say unknown publisher because stripping the storage invalidated the cert.
In Windows 7 and beyond they cache the full MSI. So this shouldn't be an issue. A further examination of your environment and uninstall log file would be required to give a better answer.
Related
I have created a vsto addin in VS2012. I have added an installation project to the solution using Installsheild LE. After installing the exe that I get, I get the expected item added to my add/remove programs. However when I open Word, I get prompted with a Microsoft Office Customization Installer prompt which says the publisher is unknown. I click OK to this and it adds my addin as expected, which all works fine but I also get a second item appear in my add/remove programs.
Can anyone tell me why I am getting the second item in add/remove programs and offer any advice about what I should do to avoid this?
You have to add "|vstolocal" to the addin registry value that points to your addin file. This tells ClickOnce to run it directly and not install it per-user.
You also want to digitally sign the addin using a certificate issued by someone in the users trusted root. This could be VeriSign or others. If you create your own certificate you have to use custom actions to install the root certificate in the certificate store and to register the publisher cert as a trusted publisher.
I've created about a dozen of these installers over the last 8 years and it's tricky at first but gets easier over time. Several of my customers are using InstallShield LE to get the prereqs installed but then I factor all the components out into a WiX merge module where I can use things like the Util extension to install certificates.
It looks like you use ClickOnce and MSI installers to deploy the add-in. You need to remove any of them. Both kind of installers are described in the following articles in MSDN:
Deploying an Office Solution by Using ClickOnce
Deploying an Office Solution by Using Windows Installer
Is that your dev machine and got Visual Studio in it? I have seen this happened with Windows 7 during development the addin is added in to add/remove programs. This has gone later when I updated my Windows 7 machine. Some updates from Microsoft has removed this later.
I have an installation setup created by LE instalshield under VS2012. This setup.exe installs the application, registers some DLLs and activeX files and adds some registry entries as pointers to the location of an SQL server database. This application is to be run by all the users in a group policy created by the IT of their institution. The installation is done under the full administration privileges.
If the UAC of the win 7 is not fully lowered, some DLLs and OCXs are not registered (although the required registry keys are written in the MACHINE area of the registry without any problem!). So in order to avoid this I have to manually lower the UAC to its lowest level before running the Setup.exe. This solves the problem with the registration of DLLs.
But sometimes even though the installed program works for the installed login, it does not work for other logins within the same group/users. So how can I create a setup.exe under LEinstallshield that would 1) not require manual lowering of UAC, 2) install for all users under the same group policy?
Thank you for all your help.
You should be asking why your installer isn't compatible with UAC instead of asking how to disable UAC. If you are authoring a clean MSI using the registry tables (COM extraction) instead of using COM self-reg or other custom actions, it should just work.
I'm logged-in as non-administrator account on Windows 2008 R2.
When I try to run the Inno-setup script under that account, I'm required to enter administrator password.
The problem is that later I can't debug that script, since it has references to {userappdata} variable, which means that during run-time it refers to administrator!
I wish not to be asked to provide administrator rights - not during debug nor during real installation. How to do that?
I prefer the application not to be installed by administrator. Respectively, files are installed to {app} (usually C:\Program Files (x86)) and {userappdata} only
How to prevent being asked to install it as administrator?
If I'd purchase a code-sign certificate for that application - would that solve that problem?
THANK YOU
There are tips already shared,
http://www.vincenzo.net/isxkb/index.php?title=Vista_considerations
If you can make your installer friendly to standard users, then the elevation can be removed. You might first set PrivilegesRequired=lowest and then see what breaks. After fixing the broken pieces, you should get such an installer.
Code signing will not stop elevation prompt, if your installer still requires elevation.
Installing anything to %PROGRAMFILES% (C:\Program Files or C:\Program Files (x86) in versions of Windows supporting UAC (and even Windows XP under a non-power user or administrator account) requires administrator rights. There's no way to work around that; the normal (non-administrator) user isn't supposed to install software to %PROGRAMFILES%.
Is there any way in InstallShield to show the prerequisites which is being redistributed along with the setup.exe are already installed on the target system, like the image below, which shows what is pending on the target system. What if I want to show that this is already installed?
There's nothing in the UI that shows this. You can run setup.exe /debuglog and read through it to figure out what was skipped:
Q105473: INFO: Setup.exe Command Line Parameters
FWIW, I get in the habit of also implementing the check in the MSI ( AppSearch / LaunchConditions tables ). This way if the setup.exe is bypassed and the MSI directly invoked you'll still make sure to not get into a bad state of missing prereqs. If this is too much work for you, you can use the SETUPEXEDIR property to enforce that the MSI was launched by setup.exe.
I have a setup which has been created using InstallScript MSI project type. This problem is encountered by our client and he wants a quick solution.
Let's assume I have initiated the installation from a path like
C:\Setup_V_1.0.0931.1
Inside this folder I have Setup.exe through which I will install the product. After installation or after some days pass I will change the path to:
C:\New\Setup_V_1.0.0931.1
and this time I want to modify the setup. Actually we are supporting 3 features: Server, Client and Service.
This time I want only Client and not Server. So I will click on the Setup.exe or click on Uninstallation Icon in the Startup Menu which will lead to Maintenance Mode there you have an option to Modify, Repair or Remove. I choose Modify and select the feature, but as the installation progresses, this error message will pop up:
Setup could not find a file on the specified path or Disk. Please check
that the proper disk is inserted or specify a new path. Unable to
locate file c:\New\Setup_V_1.0.0931.1\setup.msi
Then, another popup will be shown saying:
Error: 1706. No Valid Source could be found for product. The Windows
Installer cannot continue.
The next error message is:
Error: 1603. Fatal error during installation. Consult Windows Installer
Help (Msi.chm) or MSDN for more information.
But if I change the path to its original location, it works fine.
How can I solve this?
I event checked in this registry path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\{Product-Key}
This key contains a lot of information inside InstallProperties. There is a key called InstallSource and its value is C:\Setup_V_1.0.3909.1\. Even after changing this value installshiled is still showing errors.
I found the same registry information for Uninstallation Information:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{Product-Key}
In your properties change ReinstallMode (or maybe Reinstall I forget which) from omus to vomus
the v means cache your install, so it will put your .msi file in c:\windows\installer so it can be used later.
When installing a MSI, Windows Installer saves the original MSI path in registry (the InstallSource entry you mentioned). When running the MSI in maintenance mode, Windows Installer will use this path to find the installation data (CAB files).
When you move the MSI, the path stored in registry is no longer valid, so Windows Installer cannot find the installation data.
A possible solution is to use "Add or Remove Programs" or "Programs and Features" in Control Panel to modify the installation. This way the cached MSI is used.