If I want to install msi on remote computer in quiet mode, an receive a confirmation if the installation completed successfully or did not succeeded.
I have tried to look for a solution in windows installer API but with no luck...
Is there an event or something like that?
I have found 3 options to validate installation.
From the installation log. Need to find "return value 3" - Error value.
The msiexec process will return exit code.
Using Microsoft.Deployment.WindowsInstaller.Dll.
Related
I created an VSTO Outlook app for my job. The thing is, we need to deploy that to users without any user interaction, so in other words, silently.
I know that we can use VSTOinstaller.exe located in %commonprogramfiles%\microsoft shared\VSTO\9.0\ and use it like so in a command line VSTOinstaller.exe /install "Path_to_the_VSTO_file" /silent.
But when I do this, nothing happens, no error message and no install.
However If I remove the /silent arg, it launch the VSTO and prompt me if I want to install the app.
I tried changing the arg with /I, /i, /S or /s but nothing change.
My app is sign with a valid cert and when we get prompt, we can see the green logo
I've look at many threads about silent install for that, but it's always the same.
Do I do something wrong? Is there any other way to do that silently?
Thank you!
I am working on a Patch sample using the following link. However, I am not able to uninstall the patch either from Control Panel or from the command line MSIEXEC /i "MsiPath" MSIPATCHREMOVE="PathToMSP"
Peter Marcu's Blog: WiX: Building a Patch using the new Patch Building System - Part 3
Can anyone please let me know how to successfully uninstall or rollback a patch?
Note: I have set the AllowRemoval attribute to "yes" in the Patch.wxs file for the Patch element.
I would turn off logging, because apparently it's unable to perform the logging. Or try an explicit log location on your uninstall command line. Also, it could be this:
https://support.microsoft.com/en-us/help/2564571/-error-opening-installation-log-file--verify-that-the-specified-locate
and a detour is suggested.
I have created a Web Server setup in WiX (3.8), It gets installed correctly, but when i Repair it, I get an error 'Fatal error during Installation' and the process is rolled back. below is what i see in logs
MSI (s) (F8:C4) [12:39:26:183]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (F8:F8) [12:39:26:188]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI7B14.tmp, Entrypoint: WriteIIS7ConfigChanges
WriteIIS7ConfigChanges: Error 0x80070002: Site not found for create application
WriteIIS7ConfigChanges: Error 0x80070002: Failed to configure IIS application.
WriteIIS7ConfigChanges: Error 0x80070002: WriteIIS7ConfigChanges Failed.
CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 12:39:26: InstallFinalize. Return value 3.
Am i missing out something. Any help is appreciated, Thanks in Advance :)
If it's a repair and the site name is missing, chances are that it was entered in a UI dialog in the original install. In a repair there is no UI to re-enter the site name and properties aren't automatically saved. It may be trying to configure a site with no name. The best way to deal with this type of thing in general is to use the WiX remember property pattern on the site name so that it is preserved and is available for a repair. I can't tell if that would be a good thing in this particular case because I don't know if writing the config changes again on top of the existing config changes will work or be handled correctly by the code. A verbose log of the original install should tell you what property names are being used for site names etc.
If you think it's unlikely that the IIS config changes will break and that they won't need repair, you could consider adding "Not Installed" to the condition on the CA so that a repair won't call it.
I am trying to run an installer using the MSI command line option so that I can run it in debug mode and see the logs.
The logs that I am getting are quite large (near to 1 MB) and they are full of the following messages:
MSI (s) (F8:5C) [16:26:27:385]: Note: 1: 2360
I want to know if this is something to worry about? I have looked up the error code 2360 at Windows Installer Error Messages page on msdn and all it says that
Progress tick.
Is there something that I need to change in my installer?
I have recently added a CustomAction that makes use of System.Xml namespace. Could this be a cause?
I'm working with msi's for the first time and I see what you're talking about.
The reason you're getting "Note 1: 2360" is because the computer is writing. Writes take a long time which is why there's so many. Look at the 4 lines before the 2360. It'll be something like
Executing op: FileCopy(SourceName=somename,...)
File: <filepath>filename; To be installed; won't patch; No existing file
Source for file 'bunch of letters and numbers' is compressed
Note: 1: 2318 2: <filepath>filename
Note: 1: 2360
Note: 1: 2360
etc...
etc...
It tries to do a FileCopy of the existing file. Finds it doesn't exist. Identifies the source file. Throws error code 2318 of the new file because it doesn't exist yet (2318 means file does not exist). Then it starts writing and tells you its doing something by printing out "Note: 1: 2360".
If you ran the installer again I'm sure you'd find zero "Note: 1: 2360" anywhere in the log.
I have found some information in the comments to article posted here
> Most times these "Note:" entires are just for information but sometimes they are precursors to other errors.
posted by
Robert Flaming
Windows Installer Program Manager 1
I hope the messages that I am getting are in fact just for information.
It should not be because of Xml namespace. Please run this command in command prompt and provide the error details
msiexec /i "Path to msi" /l*v log.log
Once you get error, you can use WiLogUtl to read the log file. The tool is available with Windows SDK. Also the report will help you get exact error location
I'm using c#, .net 4, WIX 3.5, Windows Vista.
I have made my application compatible with RestartManager by p/invoking the RegisterApplicationRestart method and by handling the WM_QUERYENDSESSION and WM_ENDSESSION window messages (I return new IntPtr(1);).
If I try to update my application manually, then everything works as it should:
Launch application;
Launch msi file containing new app version;
During the installation/update, I'm prompted to close the running application;
Upon continuing the running app is closed, install completes, and the app is restarted;
If I try to update my application from the application itself, then I run into problems:
1) Launch application;
2) Download the new msi file;
3) Launch msi file with:
using (System.Diagnostics.Process p = new System.Diagnostics.Process())
{
p.StartInfo.UseShellExecute = false;
p.StartInfo.FileName = "msiexec";
p.StartInfo.Arguments = "/i \"" + downloadPath + "\" /passive";
p.StartInfo.UserName = "Administrator";
p.StartInfo.Password = securePassword;
p.Start();
}
4) Because I'm using passive mode, the application is closed automatically;
5) After the installation, my application is not restarted and under Event Viewer I have an
Event 10007 - Application or service 'MyApp' could not be restarted.
I have tried:
Not to use passive mode for msiexec;
Launch msiexec via cmd.exe (cmd.exe /C "msiexec /i ....") - in the hopes that launching msiexec from another process would solve the problem;
Wait for 60+ seconds before launching the msi update (shouldn't be relevant in my scenario, but MSDN documentation has something about it...)
But none of the above has worked (always the same result).
Having to launch the setup with elevated permissions might have something to do with the issue, because during the manual update I get a warning in the Event Viewer - Application MyApp (pid 3220) cannot be restarted - Application SID does not match Conductor SID.
Despite this, restarting the app still works. Googleing the warning yields no good/specific results, only that this warning is probably caused by running the msi in an elevated prompt.
How do I fix (or workaround) this issue, so that I can update my application from the application itself and restart my application afterwards?
Edit - extra testing:
There doesn't seem to be a need to respond to WM_QUERYENDSESSION and WM_ENDSESSION messages, because application restart during a manual upgrade works without them, so we can rule them out;
If I don't provide administrator credentials to the application initiated upgrade and instead I type them in during the upgrade, then app restarting works;
If I run an elevated command prompt and initiate an application upgrade from there (manually), then app restarting still works;
In order for application upgrade to work at all under Standard user accounts (so far I tested under an Administrator account with UAC), then I also have to set p.StartInfo.LoadUserProfile = true;. Otherwise nothing happens. (application restart still doesn't work though);
I tried all other process StartInfo parameters that I could set - WorkingDirectory, Redirect, Verb
(= "runas") - no change in results;
I installed Vista SP2 onto the virtual machine that I have been testing on (so far ran SP1), but no change;
I performed an "automatic" application upgrade with verbose logging. In the end there was an error message - RESTART MANAGER: Failed while restarting applications. Error: 352. That error code is very generic (http://msdn.microsoft.com/cs-cz/library/aa373665), inorder to get more detailed info I would have to write my own installer that would call RmGetList after the error, then I might get more details (this though is something I'm not willing to do);
Edit 2 - msi log file:
http://mommi.planet.ee/muu/log.txt
Assuming that the manual process indeed works without any problem it seems that your need for Administrator privileges in combination with the "updating itself" leads to these problems. I see the following options:
create a batch file to execute the update
When you want to update call this batch file (with elevated privileges), make the app close itself... the batch file should wait some seconds, then check whether the app is still running (and close it in case) and then run the commandline you need to run msiexec - don't restart the app from within msiexec but after a successfull run of msiexec from the batch file.
create a batch file which is always used to start the app
When the time comes to update you just end the app. Either the batch file check for an available update and applies it, starting the app after successfull update OR the app set some environment variable which is then accordingly processed by the rest of the batch file.