I have a custom bootstrapper (C# WPF) and it works well enough. If the installer gets run from the command line after it was installed, it brings up a window allowing the user to select if they want to modify, repair or uninstall. So far so good. Modify mode starts the UI which ends up calling Bootstrapper.Plan(LaunchAction.Modify). The problem is that if I call it from the launcher UI it immediately complains that a prior install requires a reboot.
I have not found any good examples on what this should do. Even the WiX mailing list came up blank.
Any ideas?
It would be helpful with the screenshot for that reboot message - just to get a feel for where it might be coming from and to get a literal string to search for. Did you have a look in the WiX source code yourself btw? (WiX 3.111 branch)
I started writing a lot of stuff about reboots. Not good. Maybe just some questions instead:
Does this happen every time you invoke modify and is it reproducible on more than one computer? Or maybe it is just Windows Update acting up on a problem computer?
I assume you have rebooted the computer where you see the problem and you see the problem again when you re-launch the bundle?
Do you schedule any reboots inside your MSI files during the initial installation?
Either using the ScheduleReboot action or a custom action which schedules a reboot with a call to MsiSetMode (for example)?
There is a long explanation here why such reboot-constructs cause problems, but that may be besides the point. Essentially badly configured reboot-constructs can trigger spontaneous, unexpected reboots without warning when packages are run in silent mode (plus other problems).
Could you try to run the test VBScript found in this answer: WiX behaving badly on XP machine with windows update issues in order to check if the script reports a reboot being necessary?
Other than that I guess you could try to run Burn yourself in debug mode (not sure how much plumbing that would be to get running) or perhaps first try a ProcMon.exe session to see if you can see something obvious. The latter should be quick to do?
There are some registry locations you can hunt down to see if you can figure out what triggered the reboot warning. Get-PendingReboot-Query. And a similar PowerShell script.
So in the end it was user error. :-( O well. I did learn a lot about how to figure out how Windows checks for the need to reboot etc.
The issue was simple in the end. During the modify run it was uninstalling, then reinstalling a number of services. The problem is that when it runs (seeing as you have to set it to repair to get it to work) it copies all the files again and the services were still running at the start of the install. The fix was to uninstall anything that might lock a file before the actual file copy starts and that solved the issue for me.
Thanks for your help guys, all the info helped me look in different directions until I found the issue. Awesome community as always!
Windows Installer self-repair can cause problems for both developers, system administrators and end users. Finding the solution can be difficult if you have limited MSI experience.
This is a Q&A-style answer intended as a check list for solving self-repair problems. Here are a few common problem scenarios:
Repeated Windows Installer self-repair might occur whenever you launch an application on your workstation. How can this be fixed, or how can components be disabled so it never occurs again?
A WiX installer may be deployed and you see repeated Windows installer self-repair whenever you try to launch the application.
When enabling or installing an MS Office addin, you experience continuous Windows Installer self-repair on application launch of one or more MS Office applications.
When working on legacy solutions in VB6 or VBA, self-repair kicks in for an unrelated product when you launch the main developer IDE.
When opening a form in Outlook, Excel or Word or similar applications, self-repair kicks off for an unrelated product from another vendor.
Keywords: Windows Installer launches unexpectedly. MSI displays unexpectedly. Windows Installer appears every time. Opening Application Starts Windows Installer. Windows Installer self healing. How does a package self-heal. MSI self-heal best practice. Windows Installer repair. Self-Repair. Disable Windows Installer. Windows Installer repeatedly runs. Application Shortcut launches installer instead. Windows Installer appears unexpectedly.
Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?
Concrete Design Advice for your WiX / MSI File
I keep trying to write about repeating MSI self-repair for developers, but end up with too much detail. Here is my last attempt: concrete design advice for what not to do in your WiX / MSI file.
The answer below provides a checklist for solving any self-repair scenarios - from any vendor or source, not just your own. Check the answer linked above for your own MSI package design concerns.
The "Short Version" - Self-Repair Checklist
To permanently and reliably fix self-repair problems for everyone, developers and setup developers must be involved since the real fix must happen at the vendor level.
If you are in a corporate environment, poor-quality application re-packaging can also cause self-repair problems, and you should involve your application packagers to determine if the problem is from the vendor or not.
System administrators must know what they are looking at, and when no fix is available, use various workarounds to deal with the problem in the wild. Even end users can try some easy workarounds themselves (see section 5).
The essence of self-repair problems:
Most self-repair issues are COM-related, and there are two general fixes for vendors and developers: 1) use the properly deployed, shared COM libraries generally deployed via merge modules, or 2) use registration-less COM to "shield" your application from self-repair and compatibility issues.
Your setup developer can implement the merge module fix, developers must test. Merge modules are standardized, shared deployment libraries for shared files.
Registration-less COM only works with developer involvement in my experience. This option is particularly relevant if the developer needs to use a particular version of a COM file (for whatever reason). Details in section 5.4 below.
Apart from COM, you can also cause self-repair problems by having your setup developer register file- and MIME-associations and command verbs in your MSI setup. Use sparingly, and ensure your file-/MIME associations are unique.
Finally you can cause self-repair by any file- or registry conflict between two installed MSI files. They "share a resource by mistake" and will treat it as its own - battling it out until the conflict is resolved.
Some self-repair problems are not caused by errors in the vendor application or setup at all, but by external factors in the computer environment in question, such as interference from tinkering users, scripts, viruses, anti-viruses or security software. See section 3 for more details.
Quick Options For Dealing With Problem Applications
Perhaps jump straight to section 5 for the list of suggested fixes and workarounds if you are sure the self-repair you see is caused by MSI alone (and not by other, external causes as described in the first few sections below).
Most of these proposed "solutions" in section 5 are really mostly system administrator tricks that don't fix the underlying problem - as stated above the real fix has to come from the vendor. The exception is "5.4: registration-less COM", which can actually help developers "shield" their applications from self-repair problems.
If you don't have admin rights on your box you are advised to try "solutions" 5.2, 5.3 or 5.1 (5.1 will generally require admin rights to try, but it is non-complicated). These are "quick workarounds", the others are more involved. If these workarounds don't work, please ask your admin to read the other suggestions.
Understanding Windows Installer Self-Repair
I have written at length about this issue before, but it focused too much on understanding the problem rather than actually finding an acceptable fix for it. You can read the full explanation of self-repair problems here: How can I determine what causes repeated Windows Installer self-repair?.
Fixing Windows Installer Self-Repair Issues
To actually fix repeated and endless self-repair, you can try the suggestions below in section 5 - in increasing order of complexity and difficulty. Before doing so, you should verify what the real source of the self-repair problem really is. It might not be caused by MSI files, but by other, external causes (such as scripts or users deleting files or anti-virus blocking files).
If the problem is indeed MSI-related, you can try to disable advertised shortcuts and COM addins, use registration-less COM, get help from the application vendor, uninstall offending applications, virtualize packages or full on hack the cached MSI database and registry (not recommended, and only really possible with expert help). It all depends on your scenario. If external causes such as scripts are at fault, you must eliminate this interference. See details below - just follow the check-list.
The first steps for problem solving are to identify that the problem really exists in the wild on your platform, and then to determine what application(s) trigger the self-repair in the first place:
1. Verify that the problem really exists in your environment.
It is generally always possible to figure out what is going on to cause the problematic self-repair, and there are several viable workarounds that can be utilized to deal with the problem. It is, however, not always possible to find a good, permanent fix (without vendor help - as described below).
Accordingly, if you are a system administrator trying to find a fix for your self-repair issue, perhaps make sure the problem is seen on more than one computer - especially if the problem is seen on a developer-, QA- or even a test computer.
If you only see self-repair problems on one computer, an alternative might be to rebuild the problem computer. Effectively eliminating rather than "solving" the problem. There is a relatively high risk that you might see the problem again though. If you ask me, don't rebuild, it is no solution - but what tends to be done in the real world I guess.
Be aware that an AD-advertised MSI install that is slow to install and keeps getting aborted by users can "look like" a self-repair issue for desktop support, but this is expected MSI behavior. Allow the install to complete once (it is possible to change the installer progress bar to disable the cancel button - something like msiexec.exe /I "MyApp.msi" /QB-! for progress bar only with no cancel button and no modal dialog at the end).
2. Identify the culprit(s) for the self-repair.
It is possible for a single application to cause the problem on its own, but typically there are at least two applications that conflict (they share some resource by mistake).
The trigger for the self-repair is generally possible to find in your event viewer on the system where the self-repair took place. Follow these steps to open the event viewer:
Right click "My Computer"
Click Manage
Click continue if you get an UAC prompt
Go to the Event Viewer section, and check the Windows Logs
Identify the offending application in the Windows Event Log by looking in the "Application section" of the event log and you should find warnings from the event source "MsiInstaller" with IDs 1001 and 1004.
You can find a lot more details on how to do this in the more elaborate answer here: How can I determine what causes repeated Windows Installer self-repair?. Look in the "Finding the trigger or culprit for the self-repair" section.
You can also try the advice from independent deployment specialist, MSI-expert and MVP Stefan Krüger. He has an article about the same self-repair issue. And he crucially discusses the actual event log entries and what they mean. Please read about the actual debugging procedure there.
3. Verify that external non-MSI causes are not causing the problem
Anything that deletes files or registry settings, manually or automatically, can trigger MSI self-repair. Especially if you are messing around deleting stuff in the user profile or in the HKCU section of the registry.
In most cases such triggers will only cause a single self-repair to run and then the problem is fixed (this is how self-repair is supposed to work and help users). Allow self-repair to run once and then launch the application again to test if the problem is gone. It should be, and your application should launch correctly from now on.
Special case: Ironically you can sometimes fix a broken application by renaming its HKCU application key (in the user section of the registry) to actually force self-repair to run and install the application's default data in the user profile - if that data was accidentally deleted (this type of fix generally does not work on terminal servers).
If the same file or registry entry is deleted again by automated means and self-repair results, you must eliminate or update the automatic process that is causing it and your problem is solved and you can stop reading. If you manually deleted the file again yourself, then you may suffer from bad memory :-).
In summary cleanup scripts, logon scripts, cleanup applications or tinkering, overactive users can all cause this kind of self-repair.
Finally viruses and also anti-virus software (and other security software) can block access to files and trigger self-repair that will never succeed.
For an infected computer, just rebuild the computer. It will save you time overall.
For anti-virus / security software problems, bring out your security guys to solve it. They may need to contact the vendor in some cases (particularly for false positives).
Whether virus or anti-virus related, check the offending file on http://www.virustotal.com to verify whether it is actually a virus or just a false positive (which can be an even bigger problem for self-repair).
Personally I have seen several anti-virus / security software related self-repair problems, but no real virus-related problems (so far). I guess viruses normally infect core system files rather than application files, and core system files are not to be deployed by MSI files (shared system files might be included in MSI files, but not core system files).
4. Contact the vendor(s) (or your own packaging department).
Once you have verified that the self-repair problem is MSI-based and it is not your own software, the first thing to try is to contact the application vendor(s) and see if they have an updated installer to eliminate the problem.
It is important to try this option since all other options are "workarounds" and not real fixes. The problem can only be completely resolved permanently by changes in the vendor installer and possibly the application executable itself.
Fix 1: The fix can be as simple as having the vendor remove privately installed but globally registered COM files with the appropriate, shared "merge module" to install the run-time correctly for everyone. These should install COM files properly to shared locations where they can be globally registered without side effect. Ready for everyone's use.
Fix 2: If the vendor claims this isn't possible - then they should be able to provide a proper registration-less COM installation with properly isolated COM files installed to the main application folder. They should also take care of deploying any security updates whenever they would come along.
Important!: If the vendor either uses the correct, shared merge module to deploy files or provides an isolated installation using registration-less COM, then the problem should be solved permanently for everyone.
The problem can also be caused by other issues, but very often COM is the culprit. Sometimes a cleanup of their MSI installer can resolve other, more obscure conflicts. If you know a good application packager, he/she should be able to quickly identify conflicts (and provide feedback for the vendor).
Note that it is also possible that the self-repair is caused by erroneous (in-house) repackaging of vendor software. In that case you can fix your own packages via updates delivered by your own packaging / deployment department (and they should definitely be able to achieve this for most cases). This is in fact a very common issue.
5. Select a "workaround" or fix to deal with the conflict situation.
If the vendor(s) won't provide a fixed installer package, you need to find a "workaround" to deal with the situation. There are several options, and some "quick workarounds" should be tried before you delve into too much complexity. Here are some problem solving suggestions in order of increasing levels of difficulty and complexity:
5.1: Just uninstall the culprit(s).
The absolute simplest fix is to figure out what application(s) trigger(s) the self-repair and just uninstall it, if that is an acceptable solution for your environment (it rarely is).
This can be acceptable if there are two (or more) applications in conflict and one of them is rarely used or "optional".
You can run the problem application on a virtual machine instead (see section 5.5). This would be my preferred "fix" for a very "misbehaving" application. All problems should disappear without any real debugging (which is costly).
Plain uninstall is an option that is at least worth considering - some software can be very problematic in more ways than one, and should simply be rejected for use. Be sure to let the vendor know that the software was rejected as well. It might be the only way to make them take the problem seriously.
5.2: Remove Advertised Shortcuts.
The first Windows Installer workaround to try is to remove "advertised shortcuts" (essentially a special type of shortcut that points to an Windows Installer application feature, and not directly to an executable or file). Read the linked article from Symantec for details on advertised shortcuts.
Note that shortcuts can be created "anywhere" including in special folders such as the "Startup" folder. This particular location means a self-repair can be triggered by itself on system startup (without user interaction).
Use an MSI viewer tool and open the system-cached MSI and inspect its Shortcut table to find all shortcuts. In order to find a list of all cached packages you can try this answer: How can I find the product GUID of an installed MSI setup? (open the package path specified in "LocalPackage").
You then re-create a regular shortcut that points directly to the executable in question. This will "bypass" the most common trigger of self-repair (the advertised shortcut). In some cases this avoids the whole self-repair issue. It is worth a try.
Be aware that even if this appears to work straight away, self-repair might still re-appear whilst you work inside the application (for example when you open a particular form). You need to "pilot" this fix with some users who actually use the application actively to make sure it is a good enough workaround for your environment.
You have also merely eliminated the symptom of the problem, the registry or file conflict that caused it has merely been "bypassed" or "silenced" - it still exists, but this may be good enough if the applications exhibit no problems during operation.
There is in fact a way to disable all advertised shortcuts on installation of any MSI package. You set the property DISABLEADVTSHORTCUTS (in one of the ways described in the link), and then all shortcuts will be created as regular shortcuts and they will not trigger self-repair. There are at least two problems:
1) The package could be designed to use self-repair to install userprofile files or HKCU settings. In this case this data will then never be added to the system as intended since self-repair will never run, and the install is effectively incomplete.
2) There is no guarantee that self-repair won't still occur - since it can be triggered by other advertised entry points such as COM invocation, file and MIME associations and command verbs.
5.3: Disable COM addins (if possible).
If your problem is related to the loading of an add-in (for Outlook, Excel, Word or other apps like AutoCAD or similar), then there are no shortcuts to tweak - the addin is loaded on launch of its "host application".
The easiest to try is to disable any addins you don't need in the addins dialog of the application in question (often Outlook, Excel or Word or similar) and see if this makes the problem go away. In some cases you are just disabling COM addins that users never used in the first place, and the problem has been eliminated.
And, rather obviously, also try to disable addins that you actually need as well, in order to check if the problem can be related to its loading. If the addin is the culprit, you should continue down the check list to the next proposed solutions (next bullet points).
I should re-iterate that the preferred solution would be a fix from the vendor (most often it would involve making the addin properly use the latest, shared ActiveX/OCX controls in question - other addins could still trigger the problem though, if they are also badly designed. You could end up dealing with multiple vendors - usually blaming each other).
In fairness to the vendors, the problem can also be caused by bad corporate application repackaging - if you are on a corporate machine. Then you must deal with the packaging department for a fix.
5.4: Try registration-less COM
Arguably this solution is more complicated than virtualization (which is described in the next bullet point), but I put it here since it might be a preferred option for some people.
Registration-less COM is something I have rarely used, but it is said to be a viable solution: Generate manifest files for registration-free COM. This essentially bypasses the registry and activates private copies of the COM files controlled by manifest file(s) placed next to the application executable(s) - effectively shielding the application from COM registry interference (in theory). "Everything happens in the same folder".
Your in-house packaging department might be able to use this to deal with "difficult vendor packages" to "isolate" their problems. However, I am not convinced registration-less COM will work properly without a few additional application tweaks contributed by the original solution developer, but I lack the empirical data to back it up. If it is an in-house app with source available, give it a test spin (and let us know).
My main problem with this approach, is that it opens up potential security holes (private copies of COM files that will never be patched by Microsoft), if you don't make sure the isolated components are updated yourself. Updates would likely cause lots of manifest-rewrite work as well (but are these old COM files updated at all anymore anyway?)
Note that registration-less COM, at least in theory, can be used for all COM related conflicts, whether they are VB6 executables, VC++ applications that use COM, etc... I am honestly not sure if it works properly for (office) COM addins (dlls) and VBA forms.
Here is what appears to be one of the better MSDN articles on registration-less COM): https://msdn.microsoft.com/en-us/library/ms973913.aspx (there is even a downloadable MSI with the samples - which ironically seems to trigger an error for me on launch).
Personally I would probably rather try a virtual package using APP-V rather than trying to use registration-less COM (see next bullet point).
It should be re-iterated that rather than "shielding" your own application - the correct vendor fix is to stop deploying private copies of shared COM files that are erroneously registered system-wide, and start installing them as intended using the appropriate merge module for deployment.
5.5: Virtualization (APP-V, Virtual Machine, etc...).
Apart from uninstalling or disabling components, the simplest fix is arguably to use virtualization to "isolate" the applications that conflict. If you still want the applications on your main SOE (Standard Operating Environment), you could try to use a virtual deployment package (APP-V). This is an application that is basically installed on demand (on launch) and runs "sandboxed" or isolated from other applications on the system.
You can also use a virtual machine via systems such as VMWare or Microsoft Virtual PC to run the problematic application(s) in their own operating system. Often people have admin rights when using virtual machines, but don't on their main SOE system (main workstation). Many developer applications are more effective to use with admin rights, so this solution might be particularly useful when dealing with development teams and their requirements.
5.6: Windows Installer tweaking - (Experts only!).
If the problem is very serious for your desktop environment and none of the options above work, you can try to fix the problem at a Windows Installer level. It might be worth it if the addin (or whatever other software) is crucial to have available on the company's main PC environment.
Essentially what you need to do is remove offending entries from the system cached MSI and/or the registry (disable advertised entry points such as advertised shortcuts, COM registration, file associations, MIME associations or command verbs, etc...).
This is very involved and not good practice to do, and there are some side-effects (for uninstall, resiliency, etc...), but it is the only "last resort" that I know about.
In these cases you would be advised to contact a deployment / Windows Installer expert and have them analyze whether a "fix" is possible. It can work, but don't expect miracles.
If you insist on debugging yourself, you need to get hold of a tool to open cached MSI files on the system (such as Orca, Installshield, Advanced Installer or similar) and you need to "hack" the database - not recommended.
5.7: Windows Installer zapping - (Not safe!).
I am including this "option" for completeness and "historical purposes" if you like. It was never a good option, and is now very unsafe on newer versions of Windows.
MsiZap.exe was a Microsoft SDK tool meant as a last-resort tool for developers to clean out failed MSI installs or uninstalls, it was never intended for widespread use. It allowed the complete "dirty unregistration" of any MSI package. MsiZap.exe is now deprecated, unsupported and unsafe to use. Use only on throwaway virtuals, if at all.
Back in the day a common "system administrator trick" was to use MsiZap.exe to "zap" a whole Windows Installer package from the system. Besides leaving your system incurably dirty, it also removed all self-repair problems for that application.
The junk that is left behind after running MsiZap.exe includes essentially everything (except the actual MSI database registration). All files, all registry entries (including COM), SharedDll ref counters (which really screw up things on reinstall), services, anything really. You will never be able to uninstall properly. In most cases you will fail to install upgraded versions of the same application without side effects. Many people actually see more self-repair problems afterwards when trying to install on top of the dirty state.
Rob Mensching, creator of WiX, Orca and all things Windows Installer has a blog post on the perils of MsiZap. MSDN describes another bad side effect: All program update information is removed when you use the Msizap.exe tool to uninstall a program from a Windows-based computer
6. Summary & conclusion
Step 4 - contacting the vendor for a fix - is the only "real fix" in my opinion.
All other proposals try to deal with the problems that result from vendor errors, rather than provide a lasting solution.
The real-world problem is that many vendors tend to blame each other, so you might be out of luck. And some vendors who do it right, do suffer from the design errors of others.
Proposals 5.1, 5.2, 5.3 are non-complicated "workarounds".
Should be safe to try for everyone.
Proposals 5.2 and 5.3 should be possible to try even without admin rights.
Proposal 5.4 - registration-less COM - is a rather involved, potential "fix".
Developer involvement might be required to find all dependent files to "isolate".
In my experience this is the kind of project that ends up taking days to try out (even with expert help) - without a real guarantee that it will eventually work.
I hear conflicting things from experts, some have succeeded, some say it fails. The people with access to the solution source seem to succeed.
Personally i don't like it for the potential security holes it opens up, and any new file versions to deploy could mean a new round of manifest re-authoring (I believe).
However the COM files in question are so old now that it is rather unlikely that they will see any security updates made to them anyway. I suppose these COM objects are mostly used for .NET interop nowadays.
Proposal 5.5 - virtualization - is a common option these days and should probably be tried before 5.4 if available in the environment. As the saying goes, "virtualize, seriously".
I honestly don't know (lack experience) if virtualization is viable for (office) addins. Please update if you can confirm.
Executables can definitely be virtualized.
Proposal 5.6 - "cached MSI tweaking" - is a "hack" that can work "good enough" when done right by deployment specialists.
There are some "side effects", particularly for uninstall - and also for "resiliency", but these should be manageable if done right.
It is the "real world" - nothing is "clean".
And proposal 5.7 - "zapping MSI" - is an unsafe, deprecated "legacy hack".
There are several side effects due to the system's "dirty state".
Total corruption of the MSI database has been reported after running MsiZap.exe.
There must be problem inside your package.
To find issue.
Clear eventlog - application.
Run your application as user with AdminRigths
Application should run after self-repair. You can run twice, if self repair will not appear,after when you run second time, it's meant that there is problem with component that want to create entry inside MachinePart like HKLM or Programfiles or Windows folder.
Open your eventlog and look for entry with source MSIInstaller.
Entry with warning will give you information what feature and component will cause self repair.
If you can show us here log from that warinig we can tell you more about your problem, but in general message inside eventviewer is clear and says what resource is missing.
Since it happens every time you launch your app (and I assume that you allow the repair to run to completion) the most likely cause is that the app removes something that is "protected" by Windows Installer, such a registry entry or a file. The shortcut initiates the repair mechanism to reinstall the missing item, and the MsiInstaller entry will tell you what it is.
In general, repairs are a good thing because they allow the user to repair the installed product if it's damaged. If, by design, there are resources that are installed but not required to be repaired then set the Component Id to null in your WiX, because that is the documented way to prevent repair of certain files, see ComponentId remarks here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx
I have an installer whose initial installation will be done by a human, but updates have to be done automagically.
Handling installer failure is a problem. I have to plan for the installer to fail: I use the <RollbackBoundary/> element in the Bootstrapper to get to a good state, and then I use both the WiX log and a log of my own devising to document the failure.
However, that's not good enough.
There's a program (let's call it X.exe). If-and-when the installer fails, I need to roll back to the state that the installer was in before the installer started and:
Restart X.exe or
Restart the target machine so that X.exe can start (I install X.exe into the startup folder of the target computer; this is also what I do for a successful install -- restart the target machine).
Deal with the problem in some as-yet unforeseen way.
Is there anything besides Logging that WiX can do for a installer failure? Is there a condition that is set that I could catch, or... anything?
I learned WiX through the fantastic book WiX 3.6: A Developer's Guide to Windows Installer XML (by Nick Ramirez), but I can't find anything to solve my problem there, nor can I find it on the interwebs.
I'm hoping there's something obvious I missed. Does anyone know how to deal with installer failure besides logging them and calling it a day?
Based on the lack of answers and lack of finding the answer to my question in existing resources, I realize that I'm simply asking Windows Installer to do too much.
I was hoping that there would be a way to do something like:
if (installation fails)
{
do something (besides rollback and logging)
}
I wonder if other installation programs provide functionality like this? Or if there's some other way to get a target machine to do something if the installer fails?
There is, in theory, but the whole area of rollback is fraught with caveats. Consider the "installation failed" dialog box and how it differs from a success case: you could run a custom action on that dialog box. But that's only if there's UI. So maybe do things from the rollback action. But what if Rollbacks are disabled? Your only mildly robust solution will be outside of the Windows Installer package.
So in your X.exe, make sure to capture the return code so you can identify a success, a cancelation, a failure, and various reboot required states. If it's a failure, then consider applying your external fix (your reboot, or whatever). If you didn't write X.exe, consider doing so, or writing something that will call X.exe.
But really PhilDW's comment gets to the core of it: rebooting on failure is not an expected behavior for an application installer. (Reboots by application installers in general are advised against.)
I'm writing an installer for an application. Most of the installer is done and working, but I have on more step outstanding. I need some way to add a setup window to the installer, that will take user input like server address and port, etc. and write these to the relevant files for system start-up. This preferably done through a GUI of sorts inside the installer.
I've tried creating an executable file that runs after installation, but this does not always execute on different systems.
Is there a way to add a GUI to the installer itself that executes after the directory structures and files have been put into place?
Thanks in advance.
In general you should seriously consider doing this as a standalone app that runs when the app first runs and needs configuring. Then it's a program that runs in a user context and can be tested and debugged in the normal way. At least consider what the user is going to do if they want to change the server address or the port - will they need to uninstall your app and reinstall it just to change the server details or the port?
The GUI may not run correctly when started from the install for a number of reasons. It may be initiated with the system account if it's a deferred CA. It wasn't started from the interactive user shell, so it probably won't have any idea of a working directory. It's being run from an msiexec.exe process running in the system directory and maybe with a system account - that's not really the place to be doing your GUI configuration.
I assume you're using WiX, it doesn't say so in your question but it's tagged with WiX.
I would have a read of http://wix.tramontana.co.hu/tutorial/user-interface-revisited (or http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/ has a relatively easy to read example), you can add or edit any of the dialogue boxes in the installer, you'll need to download the source to get at the built in dialog, and it does require some "play" to get everything quite right but worth it to get a professional looking installer.
I have a VB.NET ClickOnce application that I am trying to install on my computer. Previously, I was able to install and run these apps without issue. Now when I install the application, I can see the flash of a window opening, and then nothing. (There are also no processes left hanging or anything when viewed with the task manager.)
After some digging around I noticed that there are files in my Temporary Internet Files with names like "FusionBindError" and then my application name and different DLL names.
I have done everything I can find on the net to do, reinstall applications, reinstalled the .NET Framework, deleted my Local Settings folder and relogged in.
Does anyone out there have any other ideas for me to try?
I tried the Mage.exe suggestion, but it failed to help. Same with the other installation location suggestion. The application flashes at the bottom of the screen but does not open. I have tried using FUSLOGVW to check the bindings and nothing shows up in there. (Good or bad, there are no binding entries.)
Have you tried using mage.exe? This is a command-line tool that comes with .NET framework. Start up a VS command prompt, and try mage -cc. This will clear your applicaiton cache and will force a new click-once download. This is the first thing I do when my click-once applications fail and it works 99% of the time.
A couple of suggestions:
FusLogVW isn't working for you because you have to enable assembly binding failure logging inside the registry. This MSDN article describes how to do this.
Another thing that comes to mind is, perhaps the ClickOnce app install, or perhaps the whole ClickOnce store is corrupted. Try deleting the ClickOnce app store then reinstalling the application.
It's possible that new prerequisites were added that you don't have on hand. If the URL you are using points directly to "my.application" or whatever your equivalent is, prerequisites won't be processed.
So try pointing to the setup.exe that is created in the same directory as the .application file.
Other than that, it sounds like you're doing all the right stuff...
Also, it could be useful to run the fuslogvw utility on a machine where the application actually works. Or reflector.
And then see if indeed any of its dependencies being loaded surprise you.
Also, for these types of errors, be sure to check if disabling the antivirus resident protection helps. Sometimes it causes problems accessing assemblies' manifests and such.
I uninstalled my Kensington Mouse software, and that resolved my installation errors.
Who knew that mouse software that I never used could cause so much trouble??
Sometimes if your machine is working for days this problem will show up. Try to restart your machine. The same problem happened to me and it disappeared when I restarted my machine.