I wrote a free utility that changes system settings. Some users mistakenly think that they can undo the changes simply by uninstalling the utility. When they try to uninstall, I want to show them a message telling them that they have to use the utility in order to undo the changes, and give them a choice of continuing or canceling the uninstall. How do I do this?
I am using InstallShield LE with Visual Studio 2010.
The usual approach is using an uninstall custom action. It can prompt the user and return 0 to continue or 1602 to cancel.
This custom action needs to be a win32 DLL which receives the installation handle. An EXE or .NET custom action can return only 0 for success or any other value for a fatal error (no user exit support).
Unfortunately InstallShield LE doesn't support DLL custom actions (it requires a paid version). So a solution is to use a different setup tool which offers more control over custom actions: http://en.wikipedia.org/wiki/List_of_installation_software
Another solution is to manually add the custom action in your MSI by editing it with Orca.
Related
I'm developing a tool which will automatically install a software in PC.
I'm trying to do this with Coded UI in visual studio 2013.
To install the software I need to click on the "Next" button on setup window. But when I click on the button its showing a warning -
Access to the application is denied
Here is the screenshot of the issue -
How can i automate the process?
Is there any better approach rather than Coded UI that I should think about to install the software automatically?
Just run Visual Studio 2013 in Administrator mode.
See this thread to get more clear idea.
You can try using Win32 API methods inside the generated test method to get the window handle for the next button control and see if either 'send message' or 'post message' (win32 api methods) can be manually added to achieve the required click action. For more details about win32 api methods usage and commonly used methods please refer the below links:
https://msdn.microsoft.com/en-us/library/windows/desktop/ff468919(v=vs.85).aspx
http://www.c-sharpcorner.com/UploadFile/SamTomato/clicking-a-button-in-another-application/
What I Have Done:
I created a Visual Studio Setup Project that creates the installer for my WPF application. This installer creates the MSI I use to install the application.
I created a Primary Output with my primary project and created a shortcuts to this.
The application installs successfully.
Problem:
When I click the shortcut that was created on the desktop I get the following screen before the application loads and starts:
Header: [Application Name]
Message: Please wait while Windows configures [Application Name]
Loading Bar Header:
Gathering required information...
(Followed by a progress bar and a cancel button)
This takes up unnecessary time.
The application starts after this finishes and continues as intended.
How can I prevent this from happening, what reasons could there be for this to happen?
PS: when I open the application from the exe in the program files this does not happen.
This nearly always happens because people are unaware of the fact that if they install a file (or registry entry) and then delete it later a repair will be triggered by using an advertised shortcut. There are other entry points into repair, but shortcuts are the obvious one. Attempts to defeat repair are often pointless because there are other things that can prompt a repair of a changed product. such as upgrades, patches, and the user right-clicking the MSI to repair, or doing repair from Programs and Features.
Another cause is that the setup installs an item (such as a file or registry entry) into a user profile location (such as User's data) in an Everyone install. The is installed for the installing user, but not for another user so repair will install it. However you'd see this just once per new user.
There have also been VS setup project bugs that can cause this issue.
The documented way to prevent repair for files you want to remove after install is to null the Component Id for the file, something VS setups don't support so you need to do it with something like Orca or post-build MSI script. See ComponentId here:
https://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Note that the Windows Installer team recommends the MSI source be available anyway for a number of reasons, rule 31:
http://blogs.msdn.com/b/windows_installer_team/archive/2006/05/24/605835.aspx
Visual Studio Setup Project authors advertised shortcuts which is one of the mechanisms that MSI uses to determine if a repair is needed. It is detecting it is needed and attempting to do so but failing resulting in an infinite repair loop. Please read:
Windows Installer launches unexpectedly, for no obvious reason
This will help you identify which component is causing a problem. Unfortunately, VS Setup Projects are quiet limited and it's going to be difficult to fix this problem. I really would recommend a better toolset such as WiX, Advanced Installer or InstallShield.
I want to build a Wix installer which will detect a few programs of mine and update them.
I have c# code (using another DLL) to check a few things on the system,
then I want to download a table of the most recent version of all the apps,
decide which app I need to update, and then download & update the selected ones.
So my question is, can Wix preform the following actions:
1) run another dll call using c#?
2) download a file from the web and parse it (let's say - also using c#)?
3) go to a link and download an MSI\EXE?
4) install the MSI\EXE (let's say run it on silent mode)?
5) uninstall old other apps from system?
Windows Installer has a mutex that only allows 1 execute sequence per machine and 1 UI sequence per process. One MSI cannot install another MSI due to this limitation. There are hacks around this but they don't follow good design (don't provide proper elevation support or silent install / uninstall support ).
You should use custom actions with care. A properly designed custom action should behave like the standard actions built into Windows Installer. That is support transactional installation whenever possible and be data driven via custom tables.
A better candidate for the stuff you are describing needing to be done would probably be a bootstrapper / chainer such as WiX's Burn feature.
1) - definitely yes
2)-5) you could do it but you should differ msi from "custom bootstrapper" and "custom after install configuration manager". General rule: use msi package only for resource (usually files; in more complex cases - registry, in most cases sql objects) atomic deployment; move all other functionality outside msi (means use wix ony to build msi; create custom utilities for bootstrapper and configuration tool; see wix samples how to integrate three parts together).
1) Yes but keep in mind that if you have a dependency on .NET 3.5 and you are on a box with .NET 4 your custom action will not be able to run.
Besides this your custom action dll is unpacked from the msi into the %TEMP% folder. If you have any dependency to other dlls not stored in the GAC you will fail to load. If you bring in another e.g. C++ dll you have to embed it as resource in your C# dll and unpack it as well to find it.
2) You can do whatever you have the rights for.
3) Sure
4) Only one MSI installation can run at one time. You have to spawn some child process to wait until the current installation is over.
5) Yes sure. The easiest way is to add an Upgrade table to your msi to simply uninstall any software which has this upgrade code. This is the only allowed action where two msis at the same time can be active. Look at the InstallExecute Sequence table for RemoveExistingProducts action.
I have created a c# 4.0 windows service. I have created an installer project (.msi) for it which installs the service to a particular folder.
To automate the process fully, I would like to install the service as part of the custom actions I have for my installer.
How can I code my custom actions to install or when uninstalling the msi, uninstall the windows service?
You can use the ServiceInstaller class. A quick solution would be to find installutil tool and execute it against your Service.exe, but you have to capture the output to see whether the installation succeeded or not and you don't have much control over Install, Commit, Rollback, and Uninstall phases.
Simple answer: don't. The proper way is to install it using the MSI database itself, i.e. ServiceInstall and ServiceControl tables. Every single "convenient" IDE for MSI creation and also WiX come with primitives to make use of this builtin facility.
The very reason that this is best practice, just like including the COM registration in your MSI instead of calling DllRegisterServer of the COM (DLL) to register is that your application may be defunct at the time the user attempts to remove it.
The database actions can still be executed even by a newer Windows Installer, say after an upgrade of Windows itself, while your code may refuse to run or may not run for other reasons.
I am currently adding a deployment project to my C# solution which
installs a windows service and I have been trying to find a property
that will make the installer prompt the user to reboot the system once
installation has completed. I would prefer to simply set a property
rather than create a small application that I run at the end of the
install.
if there is any code to restart then where i'll use this code
in installer class or elsewhere?
If you use a MSI-based installer (which would be the case if you're using a VS setup project), setting REBOOT=Force should do the trick.
Under normal circumstances, though, the installer will itself detect if a reboot is needed: if you're not currently getting a reboot prompt, that's a good indication your service should work just fine without that reboot.
You may be able to extend your setup logic to start the service after installing it (and also to launch any auto-start GUI components if required). That's much friendlier than forcing a reboot, and you'll do your bit to help Windows get rid of its "you moved your mouse, please reboot" image problem...
Edit (December 2011) #IdentityCrisisUK: see HOW TO: Control System Restarts in a Setup Project That You Created by Using Visual Studio .NET for the exact steps involved in setting the REBOOT variable. Use of Orca is required -- not sure why that has "already been ruled out", as it's a trivial postbuild step...
Use the REBOOT Property of WIX to restart prompt in the Product.wxs file of your Setup. Syntax is :-
<Property Id="REBOOT" Value="Force"></Property>