What is the correct way to display UI during a custom installer action?
I would like my UI to be modal on the install dialog, or alternatively, I'd like a way to display text/progress from my custom action in the installer dislog.
The installer is a VS2005 setup project and the custom action is a C# Installer-derived class.
Displaying any kind of non-standard UI would require changes to the UI handler object. This isn't trivial, and the implementation depends on the toolkit you use to author your MSIs: I'm not sure it's even possible with VS setup projects.
Displaying simple status/progress messages and logging to the MSI log isn't too hard to do from a custom action, though, at least not using the Windows Installer XML (WiX) toolset, which is what I use myself for this purpose.
When authoring your custom actions with WiX, you get access to the active installer session through the Microsoft.Deployment.WindowsInstaller.Session object, which has 'Log' (writes a message to the log, if logging is enabled) and 'Message' (performs any enabled logging operations and defers execution to the UI handler object associated with the engine) functions, amongst many other goodies.
If you're currently already creating your custom actions in C#, you may be able to find something similar in your current environment (I've never worked with VS.net installer projects, so I'm not exactly sure how they work -- I'm quite surprised actually that these allow you to create managed custom actions...). Otherwise, I'd definitely recommend looking into WiX for custom actions: these work with any MSI authoring environment, and are quite flexible.
Related
I'm having troubles with some could I would like to execute when the service will be uninstalled. I've added the code to both the System.ServiceProcess.ServiceProcessInstaller BeforeUninstall event, and
to the override method OnBeforeUninstall, but that did not work too.
When using my InstallShield msi to uninstall the service this code does not get executed.
How can I force the service to launch some code during uninstall? Do I need to use a different event in my C# service? Do I need to change something in my MSI?
Note:
My problem is identical to the following
https://community.flexerasoftware.com/showthread.php?149176-MSI-Uninstall-NET-Service-does-not-launch-BeforeUninstall-event
Thanks,
sagar
You'll need to be more explicit about everything you've done. For example there is no automatic calling of installer class methods unless they are explicitly added to your setup as custom actions (in your case an uninstall custom action). You should also explain exactly how the service was installed.
Note that installer classes were invented by Visual Studio setups, and there is typically no need to use them because tools like InstallShield usually support the standard ServiceInstall and ServiceControl functionality in Windows Installer. Installer classes are unnecessary. Also, those events are Visual Studio specials, and it's not clear to me if InstallShield supports them. If you are using an Uninstall method to uninstall a service then just add your "before" code to before the Base.Uninstall() call.
If you want code to run when the service is uninstalled, the more usual way is to have a custom action that calls your code, and condition the call on REMOVE="ALL" (for an uninstall) or other conditions depending on your exact requirement. For example, if you do an upgrade MSI to upgrade your existing product do you still want to run that uninstall code?
.NET Installer Class: PhilDW has already said it all, but I just want to add a couple of things. I assume you are using System.Configuration.Install.Installer and the ServiceProcessInstaller Class (there is a sample in the Installshield help file). There used to be (and I think there still is) a flag for each Installshield component called .NET Installer Class. You can set this flag to Yes, and then I believe Installshield itself will take care of running your installer class methods (Install, Commit, Rollback, Uninstall - whichever one is implemented I think, but I have never tested all scenarios. I don't use this feature).
InstallUtil.exe: Running InstallUtil.exe would indeed call these methods. I am not sure how Installshield calls the methods under the hood (during setup execution) - they may actually be calling InstallUtil.exe for all I know, or some more low-level API call.
Conclusion: Just go to the components view and click on the component containing your service.exe file - and set the flag mentioned above. The exe must be a key-file for the component in question - and it must be a .NET assembly. Like PhilDW wrote, I wouldn't use these methods since they are intended to be used during service development only - not during deployment. For one thing you could run into runtime errors when the methods try to run faulting your whole setup (and often unnecessarily so), and there are also likely issues with rollback and potentially other problems. Can we ask what the methods are actually doing? Perhaps you are just deleting some log files? There are other ways to do that - most significantly using the RemoveFile table.
I'd like to show the serial number in the CustomerInfo form (which was captured from the first install and installed in the registry) within the second, third, etc installs when the upgrade is simply a minor version change (or patch). Is this something that can be done within VS deployment project and/or WIX via a custom action (I have a C++ method to fetch the SerialNumber from the registry), MSI config (thru editing a table(s) via say Orca), or otherwise
Regards
Travis
Personally I always do PerMachine installs and don't bother to show the customer information dialog. If an application wants to have licensing it's best to do it in the application on first run.
If you really want to do it in the MSI, you've got a lot of work ahead of you. MSI doesn't persist properties across transactions so you'll have to do it yourself. See:
The WiX toolset's "Remember Property" pattern
I have an open source project called IsWiX. It includes a Visual Studio project template that creates an installer project framework. Part of that framework shows how to insert a custom dialog and then authors a component to handle the remember property for the control on that dialog. You can find the source here.
I'll skip the WiX part that Chris covered.
To do this in a VS project you're supposed to use the Customer Information dialog, added from the list of extra canned dialogs, and use the SerialNumberTemplate stuff. That sets the ProductID property which is the way you're supposed to do serial numbers. So then you could create a registry item in the Visual Studio IDE that has the value [ProductID] to save it somewhere personal. The "official" way to get hold of it for an installed product is MsiGetProductInfo() or equivalent passing the ProductCode and asking for "ProductID" as documented here:
http://msdn.microsoft.com/en-us/library/aa370130(v=vs.85).aspx
To summarize, if the package uses the official PIDKEY /ProductID mechanism (like VS and maybe WiX) you don't need to save it yourself and you can get it via MsiGetProductInfo() or a scipt/managed code equivalent.
If you want to show that previous SerialNumber in a VS setup in the standard customer information form on an upgrade, I don't believe you can do that. There's no mechanism for getting into those forms. If you save the SerialNumber privately, you could try a registry search for your saved serialnumber and store it in the PIDKEY property to see if it shows up there, that might work because the PIDKEY property is the source for that value.
I have just started playing around with Burn to try and chain multiple MSI files. I am using WiX v3.6.2705.0.
The chaining is working but I'm now trying to get optional features to work. I was hoping that it would just be a case of setting EnableFeatureSelection to "yes" for my MsiPackage tags but it doesn't make any difference whether it is turned on or off.
Is there anything else that needs to be done to get optional features working or is this a known issue?
Thanks,
Alan
If you want to display the features in a UI for the user to select then there are two options:
Create a custom bootstrapper application using Burn to collect information from the user, and then pass that information to the msi when you launch it.
Custom WiX Burn bootstrapper user interface?
wix-burn-3-6-beta-custom-ui-examples
If you have authored a UI into your MSI and you want Burn to display that UI in addition to the Burn UI, then in your MsiPackage, set DisplayInternalUI="yes".
You ca use the MsiProperty element to populate the ADDLOCAL property with the features you want installed by default.
NOTE:
MsiProperty ADDLOCAL - Removed in Wix 4, warning and ignored in Wix 3.11
Dozens of Q&A entries (all but one in stackoverflow!) that I found got close to this question, but didn't teach me what I needed. I have what should be a nearly simple installation: a Windows service and an associated tray icon application. They install fine with the standard VS Setup project. After the files are installed, I need to present a dialog to the user to set some parameters in the service's exe.config file. In that dialog, the user should be able to abort the installation. I've tried two approaches to the Custom Action process and ran into a wall with each when it comes to making the installation roll back.
Approach 1: An exe for the Custom Action, run at Commit time.
This sort-of works. The application returns a non-zero exit code and the installation rollback occurs. What I don't like is that:
When the app exits (after the user selects to Cancel), the installation displays an error message saying that there was a problem with the installation and the user should contact the vendor. Since that's not the case, I'd prefer a more correct message ("Installation canceled by user") or no message at all.
Both of the project outputs (the service and the tray app) have to be listed under all four Custom Action sections or my dialog won't appear. Instead, an error appears about a missing InstallState file and the installation always fails. Intuitively, this seems wrong.
Approach 2: An Installer as the Custom Action, run at Install or Commit time.
This is cleaner to me (only the one item listed in the Custom Actions), but getting the process to roll back is worse than Approach 1. It seems that I have to throw an exception in the overridden method (Install/Commit), which then gives me several error dialogs before the rollback occurs, and then the rollback doesn't always uninstall the service.
What is the cleanest way to make this work without going to WiX or similar options?
The simple answer is don't use VS Installer Classes. They have a number of fundamental design flaws. I suggest you look at Windows Installer XML's ( WiX ) Deployment Tools Foundation ( DTF ) instead. DTF is a far superior hosting model / interop library for your managed code and outputs DLL's that are compatible ( from an MSI perspective ) with C/C++ custom actions. They can be consumed as Custom Actions by any MSI authoring tool, not just WiX installers.
Deployment Tools Foundation joins the WiX toolset.
Deployment Tools Foundation (DTF) Managed Custom Actions
I recommend this approach:
create a custom installation dialog which asks the user about your options
use the installer properties set by this dialog to modify your service configuration file (you can use a custom action or the XML support of another setup authoring tool)
This way the information is gathered before the install and the user can also abort the install without problems.
This approach is not supported by Visual Studio, but it can be done with free or commercial setup authoring tools.
If you want to stick with a custom action, you can try this:
make sure your custom action is deferred and doesn't run during commit (commit means that the installation was performed and there's no rollback)
use a Win32 DLL to show your custom dialog; this way you can return ERROR_INSTALL_USEREXIT (1602) so a friendlier user exit dialog is shown instead of the fatal error dialog
I'm currently developing a window application in VS2005,i need to make a setup of the product..and i had used setup and deployment project in VS2005 and created the setup but in the setup process... dialogs cannot be modified.. according to my needs...(ie it will be the same for all products installation only can change the heading , product name or top-banner) i like to make a setup the look the normal software installation...(like Visual studio ,photo shop installation)how is it possible to make a custom setup method..Is there any Custom setup & deployment method which is easy to do...plss help..me to create a better view during the product installation
There are several options: You can use InnoSetup, which is free and very powerful. It has its own script language and you can create new dialogs and behaviour using integrated Pascal scripting.
You can also use Windows Installer XML. This will create professional MSI installers, which are also customizable. You use an XML dialect to describe your setup here.
My experience is that InnoSetup can be used easily (there are tools linked on the home page for visually creating the setup) and creates very professional setups.
WIX is also pretty straightforward, but you have to learn a little more in advance. However, "standard setups" can be created very easily as well.