I have a created an installer using WiXStandardBootstrapperApplication. The intention is to run it silently and I do that using the /quiet flag and it runs silently just fine. The way it runs is, as soon as I enter the command on the command prompt the control returns to the command prompt instantly and the installation happens at the background. So if there are any errors or even in the case of Success, I don't know whether it completed fine or for what reason it failed. In linux, I can run a command silently and the console will show the progress of what are the things that it is doing. Can I do something similar in Windows? I initiate the command and the logs are displayed on the console or at the very least a Success or Failure message is shown on the console window before it stops the execution.
I am aware about the messages being logged in the log file but wanted something to come on the console itself. Thanks for your help in advance.
The point of /quiet switch is to have a silent installer. That contradicts the requirement to show any UI. If the installer encounters any errors, it will return exit code other then 0. Details about the failure are in setup logs.
WiX does not do any console logging.
Related
I just watched at a customer site the execution of an MSI of ours that needs elevation, because it is a per machine install. The operator at the customer site was logged in as a consent administrator (i.e. with a restricted admin token) and simply launched the msi package of ours with a double click, went through the UI pages in order to finally hit the "Install" button on the standard WIX "Ready to install" page. What you would normally expect now is an elevation prompt, so the per machine install can be performed. What happened today when I observed this, was an attempt to perform the installation without administrative permissions, which surprised me. The install soon showed an error message stating "insufficient privileges" and a rollback was performed.
I have never observed such behaviour before. What could be the reason that the install does not "self elevate", i.e. does not show an elevation prompt after hitting the button "Install"? Is there any windows configuration setting that causes this behaviour? The computer in question was running Windows Server 2016, in case that matters.
Any help appreciated,
--
Stefan
I ran into a very weird problem today with my C# application. I downloaded it today (from a trustworthy source my classmate sent me back the program we do together) At first when i tried to build and run the application, the whole visual studio got frozen and the app didnt even appear. After a lot of trying this problem just disappeared all of a sudden. However, now I cannot even build the solution, because I get the "unable to copy file because it is being used by another process" error message. I checked the task manager and the program runs in the background. I cant kill it because I have no access to do that(access denied message), I cant do that with a terminal command either(Because the terminal says this exe file is not running) and what is more even restarting my pc 2 times didnt make it disappear. It is no more in the processes after a restart, but i can still see it in the details view of the task manager.
I just have this program running in the background literally forever now?
Someone could explain me what even happened and if there is any way to solve it? I could even code (and build) the program for a while!
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!
I want to check if a process is running before installing a new add-in using the advance installer. To make that, in custom Actions, I select detect process and put the process that I want to stop. With that I get AI_PROCESS_STATE Running or Stopped. But now I don't know what to do to stop the installation if it is Running or at least show a message telling that is necessary to close it before continue.
There are options like display message box but if I put them they always appear. I don't know how to make them appear only when AI_PROCESS_STATE has the value Running.
There are several problems here:
The general way to do this is to call a custom action Dll that looks for the process, and sets an installer property if the process is running, then you can fail the install with a type 19 custom action and your own error message. Running a process doesn't give you a good way to return a value into the install so you can show an error message.
However, getting the list of processes requires elevation, and by default you're not elevated at the start of the install.
Are you sure you're not inventing a problem? Why should the user shut down the process? The user-friendly approach is to register your add-in and tell the user they may need to restart the app before their new add-in will show up.
I am new to programming in Go. I would really like your help regarding one of my problems.
I am required to do go install on a file, the executable of which (in Windows) is created in a folder called GOPATH\bin.
Until now, I typically followed the routine: go install <file>.go ---> <file>.exe.
However, this time it appears that after the execution of <file>.exe, the exe doesn't finish complete executing for a while and I get the following error when I go install again.
C:\Users\Rahul\Desktop\Compilers\src\cs553s2013\mylexer>go install
is_digit.go go install command-line-arguments: open
C:\Users\Rahul\Desktop\Compilers\bin\is_ digit.exe: Access is denied.
See http://grokbase.com/t/gg/golang-nuts/135fyje5d9/go-nuts-go-build-access-is-denied-windows-7x64
Absolutely no idea why, but the above suggestion worked. One must enable the "Application Experience" windows service on Windows 7 to solve this issue.
I had this service disabled, and was seeing a similar strange 2-3 minute time of "Permission Denied" on my project's binary (the binary would also disappear after a refresh via alt+F2 of $GOPATH/bin, from a Windows Explorer view of the $GOPATH/bin where Eclipse + Goclipse was building my binary). I noticed that just after execution, and before the binary finally disappeared, it was changed to be owned by some unknown user (in Explorer, it isn't owned by the compiling user, Administrator, or even SYSTEM).
I can only speculate -- perhaps Windows keeps any .exe on the filesystem, if it has exited without some sort of undocumented 'all-OK' status to the windows kernel, assuming it 'crashed', so the Application Experience service can send it as diagnostic data to Microsoft -- and if that service is disabled, the Application Experience service can't finalize whatever handshake NTFS or Explorer is waiting for to allow the file to be overwritten by subsequent compiles. So the golang .exe sits there, with elevated permissions, with some system/undefined user, un-deleteable by Eclipse, until Explorer does something to mark it as definitely dead.