I am using WiX and want to know if we can disable a control in a built-in dialog. My requirement is to disable the "Browse" button in the "CustomizeDlg".
This became too long for a comment. I might "evolve" it as an answer if we get more information about your scenario. Just a couple of heads-ups for you.
If you are trying to prevent the setup from being installed to a non-standard path, then you should account for the fact that the installation directory can be set at the msiexec.exe command line when the setup is installed in silent mode. Sample (untested by me - first thing I found :-) ).
I suppose a custom action could be used to abort the setup if it is installed in silent mode to a non-standard path? An immediate mode custom action before InstallInitialize somewhere I guess, but after costing actions (CostInitialize, CostFinalize, FileCost, InstallValidate, etc...) - but frankly, why do this? Perhaps you could illuminate your use-case?
Oh, and please don't leave the standard action RemoveExistingProducts to run before your custom action (in the InstallExecuteSequence). This would remove the existing, related installation on the box (if any) and then abort the major upgrade operation leaving no install left on the box.
And don't add your custom action to the user interface sequence - there is no need. This sequence is entirely skipped in silent installation mode, and if there is no way to set a custom path in the GUI, it can't be changed there anyway (and the InstallExecuteSequence's custom action would catch any changes should they be set anyway - it will do).
Per this thread which discusses how to enable the button, what you need to do is the reverse: ensure your Feature elements do not specify a ConfigurableDirectory, or that it is not public by using some lowercase letters in the identifier.
Related
I'm creating an installer at work that must open a file browser. There is no file browser in wix, so I built a custom vbscript action that uses the Shell.BrowseForFolder method. It's working fine, but the file dialog shows up behind the main wix window. Does anyone know a wix/vbscript approach I could take to solve this problem?
Locate the HWND for the MSI UI and pass this into Shell.BrowseForFolder. I see a few example solutions that use FindWindow("MsiDialogCloseClass", vbNullString). Be careful about launching UI from a custom action: you need to consider silent installs/repair/uninstall, etc to make sure you get it right in all cases.
It looks like you're trying to allow the user to pick a directory. MSI has native support for this. I reccomend you use that. For an example see http://wix.codeplex.com/SourceControl/latest#src/ext/UIExtension/wixlib/BrowseDlg.wxs.
I have a custom action which pops up a dialog. I would like to suppress the custom action using a condition property if my installer is being run in quiet mode (ie. /q in msiexec). How do you do that?
I know I can use a property:
msiexec /i .msi /qn SUPPRESS_MY_CUSTOM_ACTION=1
and then
use Condition property of:
NOT SUPPRESS_MY_CUSTOM_ACTION
But, it would be better to just be able to know if I'm in quiet mode.
Custom actions scheduled in the execute sequence should seldom have UI. A rare exception would be an abort, retry, fail type dialog where a retry could result in a successful installation. The custom action should check the built in UILevel property to determine if it's appropriate to display a UI.
You probably don't want to suppress the custom action completely as certain default assumptions can probably be done without a UI. Otherwise you might also want to consider factoring the custom action out into the UI sequence and Execute sequence.
Agreed with what Christopher says. But in addition to being able to condition off of UILevel (which works in either the action's condition, or inside the action's code itself), there's another approach. Change how you put up your UI from calling something like MessageBox directly to instead call MsiProcessMessage (with e.g. INSTALLMESSAGE_USER) to have Windows Installer show the message box. It will internally handle the equivalent of checking UILevel, but note this other approach will not work from a Control Event.
I am a bit of a beginner at InstallShield (in the sense that this is the first time I've used it!).
I have some code that I am packaging up in a .net DLL to check for the existence of anti-virus. The installer I am attempting to create must check for anti-virus (by calling a custom action using my DLL?) and cancel the install if none has been found.
The way I seen it working, was the user would see a dialog that is informational ("about to check for anti-virus"), the user would press "Next" it would call the custom action and then show a success screen with a "Next" button, or a failure screen with "Finish" button.
Is this sort of thing possible with InstallShield? Are there any good tutorials out there for doing this sort of thing?
Do you really need a custom action? Do you have more detailed requirements with regards to what products and versions you are looking for?
InstallShield / Windows Installer has a built in search pattern that can look for registry entries, files, et al.
If you really do need a custom action, how long do you expect the execution to take? If it's only a couple seconds, just schedule it to run after AppSearch. You don't need a UI to say "now doing blah" just do it.
Since you want to do this in .NET, you need to look at Windows Installer XML (WiX) Deployment Tools Foundation (DTF). You can use this to author/compile custom action DLL's that InstallShield can then consume. Generally the custom action should do it's search and then set a property based on it's result. Then use that property in evaluating whatever business rule you are trying to implement.
I am developing a WiX installer (I am very new to this) and want to implement a method (like launch condition) which check if a particular application is running or not. If it's running then a warning message will popup displaying close the application message. I want this check before the welcome screen.
How can I implement this? Some working example will really help me a lot.
Windows Installer already has a FilesInUse and RMFilesInUse (Restart Manager) support. Does this not meet your needs? With these patterns you'll get a dialog telling the user that they need to exit a program or risk needing a reboot.
This can be done only through a custom action. Here is a tutorial for a C++ DLL native custom action: http://www.codeproject.com/Articles/1747/MSI-Custom-Action-DLL
Your custom action can perform the check and then show a message to the user if necessary. It
can return 0 to continue the installation or 1602 to stop.
To show the message before Welcome dialog, you can try scheduling your custom action right after CostFinalize action in InstallUISequence.
I'm making an installer that uses certain custom actions. I want to create a rollback action that undoes this changes when the installation is cancelled or unsuccessful.
What I've tried so far is what the documentation tells you to do, which is call the CA in deferred-mode and set "rollback only" in the In-Script Options. if you cancel the installation, the moment the installer tries to call the CA, the installation fails, it doesn't matter what the content of the CA is, it always fails the moment the installer tries to call it.
It says the installer couldn't execute a find a program necessary for the installation (the CA), even though the CA is called with "Run WiseScript From Installation", so the CA SHOULD be there.
It sounds like the setup is hitting an error inside your rollback custom action. The first thing I would do to prevent the setup from bombing out would be to mark the rollback custom action with "don't check exit code".
I haven't used Wise in a while and don't know exactly where you find this in the GUI, but it shouldn't be that difficult. It is probably a flag you can set when you insert the custom action into the InstallExecuteSequence.
Secondly you would need to start debugging the actual content inside the custom action to determine where it crashes and obviously resolve the root of the problem before the rollback action will work properly. Sometimes it is sufficient to just use numbered message boxes to track the progress of the code in the custom action at runtime, but at other times you need to use the debugger feature to step through each line in the custom action code.