I'm using Inno Setup to build our installer. When I uninstall, the entry created in the "Programs and Features" control panel isn't removed.
We define CurUninstallStepChanged to remove a file and InitializeUninstall to ensure our Install isn't "active" (running). But I didn't think that would cause the entry to remain after an uninstall.
Any ideas?
Thanks,
-Mike
"Programs and Features" values are read from registry.
You need to delete appropriate registry keys to delete your item from this category.
By default Inno Setup generates installer/uninstaller which creates/deletes these keys.
Are you doing something extra in your script which
a) writes additional registry keys?
b) prevents from deleting them?
Related
I need to change ConfirmUninstall, UninstalledMost (just in case), and UninstalledAll specifically from script to set a condition. Something like this:
if FileExists(ExpandConstant('{app}\Slash.exe')) then
SetupMessage(msgConfirmUninstall) := FmtMessage(SetupMessage(msgConfirmUninstall), ['Dagon Slasher'])
else if FileExists(ExpandConstant('{app}\Frank.exe')) then
SetupMessage(msgConfirmUninstall) := FmtMessage(SetupMessage(msgConfirmUninstall), ['Dagon Frankenstein'])
else
SetupMessage(msgConfirmUninstall) := FmtMessage(SetupMessage(msgConfirmUninstall), ['Dagon Video Tools']);
But this doesn't work. These messages are used in MsgBoxes, so I can't think of any other way. Running in silent mode is not really suitable for me, since setup will run uninstall if the programs (or one of them) has already been installed, so I don't want the user to accidentally uninstall the program by running the setup.
You cannot change these easily, see:
Replace or customize modal uninstallation windows in Inno Setup
Regarding the silent uninstall solution: I do not understand your problem with "setup will run uninstall if the programs (or one of them) has already been installed".
I assume you run the uninstaller only after the user confirms (s)he wants to install the new version, so you actually want to run the uninstaller silently, right?
And anyway, there's nothing that prevents you from running the uninstaller non-silently from your installer, even if the entry in "Add/Remove programs" refers to "silent" installation.
You can use generic messages that covers all setup types:
[Messages]
ConfirmUninstall=Are you sure you want to completely remove this game?
As your uninstall messages depend on a type of the installed application, you can modify the installer to:
Create custom "type" page (like a menu) as the very first one.
Once the user selects the "type", restart the installer with a custom switch (e.g. /APPTYPE=slasher) and exit.
Once the installer is (re-)run with the /APPTYPE, you know from the beginning, what component/type you are installing and hence you can set the AppName accordingly (using a scripted constant).
Of course, you skip the custom "type" page.
This is actually not difficult to implement. The only drawback is that the setup window is "recreated" after the user selects the "type".
I've sketched this solution already in my answer to Inno Setup Change AppName based on component(s) selected.
Is it possible to use same Inno Setup installer for installing new or updating/upgrading application. For example If the application is already installed the installer will check current version against newly availible. If it is true then I would like the installation procedure to be silent, meaning showing only the progress of update and not all availible installation features (e.g. folder location e.t.c). Thanks.
=======
The solution to the problem was :
Passing the parameters /SILENT/SUPPRESSMSGBOXES
taken from
http://www.jrsoftware.org/ishelp/index.php?topic=setupcmdline
For the standard screens, simply add the following to your [Setup] section:
[Setup]
DisableDirPage=auto
DisableProgramGroupPage=auto
This will automatically hide the directory and group selection pages on subsequent installs (using the previously selected values, by default, unless you've used other settings that disable that behaviour).
Components and Tasks will still display, but that's usually a good thing as it allows the user to add additional components or re-perform certain tasks. (Note that you can use the checkedonce flag on [Tasks] entries to only tick them by default during the initial install, but allow the user to re-tick them manually if required.)
It's possible to skip even more pages through use of [Code], but this is rarely necessary.
Another option is that if the installer is being run from your application itself (eg. as part of a "Check for new versions" task) you can use the /SILENT command line parameter to hide the normal interactive UI.
I'm using NSIS to distribute my software. It's basically a plugin to view custom 3d content and is delivered with one content package. Since I'm distributing the contents separately each content package has it's own installer with the same software. The problem is that each time I install additional content, the uninstaller gets overwritten and so the uninstaller only knows about the last installed component.
Would it be possible to write a registry entry for each content and then generate the component list of the uninstaller dynamically?
I'm open for any other advices how this could be achieved.
Best regards,
Satara
They easy way is probably just to give the uninstaller a unique name for each content package and if required, keep a count of installed packages under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls so you know when to uninstall the engine/plugin.
The number of NSIS sections is set at compile-time and you can not add more so if the maximum number of packages is unknown you cannot just make some of the sections unchecked & hidden. The way around this is to store a list of the installed packages somewhere in the registry and create a custom page (nsDialogs) in the uninstaller where you list the installed packages...
I've searched all over for a solution and have not been able to get them to work.
My company's product used to have the Repair option when selecting the product in the Programs and Features dialog. You could also right click on the product and select Repair there as well. Just before I inherited the installer projects, this Repair option disappeared. I looked around to see if anything was disabling this option and couldn't find anything.
In InstallShield DisableRepair is set to No. There also is no registry key set in the Uninstall section for the product for NoRepair when the product is installed. By default, I believe I should be seeing the Repair option and don't understand why it's not there. I've tried messing with ARPNOREPAIR in custom actions, all to no avail. I even created a registry key for NoRepair with both 0 and 1 for DWORD values to see if it actually would work and it did not. I'd like to say that there is some code somewhere that is disabling it, but I've checked everywhere and even talked to the previous installer coworker and he doesn't know of anything removing that option.
Does anyone have information on this?
After lots of digging around and testing I have found out some interesting things and a solution to my issue. It turns out that there was a C# custom action that was creating a separate registry entry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. Also, ARPSYSTEMCOMPONENT was being set to 1 in InstallShield which was disabling the original entry from showing in Programs and Features, while the new entry was set to show. Apparently NoModify and NoRemove work with the new entry, but not NoRepair(no idea why this is). My solution was to go back to the original entry and modify the keys that I was adding in the custom action.
What sort of resharper specific files does resharper generate in your vs.net project?
(BTW, did you guys get the full version or just the C# version?)
The "_Resharper.[Solution Name]" folder stores the Resharper specific cache. You can go to Resahrper > Options dialog and select "Store caches in: system TEMP folder" so that your solution folder is not cluttered.
I personally prefer to use the TEMP folder so that the cache does not accidentally get added to the version control. Also, in case you want to clean the cache you can use the "Clear Caches" button on the Resharper Options dialog.
Couple of different things:
A folder called "_ReSharper.[Solution Name]" which then contains a collection of files and folder beneath that
A file called "[Solution Name].[ReSharper Version].resharper.user"
Both are created in the root of solution next to the .sln file. You can delete them if necessary and ReSharper will just recreate them on next load. Keep them out of your source control management system - they serve no purpose under verison control.