I'm building an installer using advanced installer and have run into a problem trying to add dates into the log file. I tried a command using cmd which worked, however when I added it to the MSI commandline all the date values came out as blank. Below is the parameters I pass for the MSI
/L*V "C:\Log_%date:~4,2%.%date:~7,2%.%date:~10,4%-%time:~0,2%.%time:~3,2%.%time:~6,2%.log"
We are trying to make the log be Log_04.05.2019-15.03.45.log instead of Log.log since the logs get overwritten when uninstall happens or on a retry of an installation..
Advanced Installer: Sorry, I see that I must have misunderstood. You are trying to set the log file name from within Advanced
Installer. Will have a quick look. Where do you specify this command line in the tool? Please note that setting the logging policy for "Global Logging" will ensure unique log file names and that every MSI operation is logged in TMP.
Clarification: So it looks like you don't want to write to the log, but to control the file name of the log file itself?
PowerShell: I find batch files clunky with regards to stuff like this. Can you invoke the installation via Powershell? I don't really use PowerShell, but seeing as it can use .NET, maybe a simple conversion of this C# call would do the trick?
You want something like: "Log_04.05.2019-15.03.45.log", so you could perhaps try this in C#:
Console.WriteLine("Log_" + DateTime.Now.ToString("dd.MM.yyyy-HH.mm.ss") + ".log");
Here is a blog on using PowerShell with Windows Installer, see towards the bottom for this PowerShell snippet (again, I do not use PowerShell for this purpose):
$DataStamp = get-date -Format yyyyMMddTHHmmss
$logFile = '{0}-{1}.log' -f $file.fullname,$DataStamp
$MSIArguments = #(
"/i"
('"{0}"' -f $file.fullname)
"/qn"
"/norestart"
"/L*v"
$logFile
)
Start-Process "msiexec.exe" -ArgumentList $MSIArguments -Wait -NoNewWindow
Maybe also have a read about the Windows Installer PowerShell
Module (Heath Stewart) as linked to in this general purpose
answer:
How can I use powershell to run through an installer?.
Special-purpose PowerShell Module making Windows Installer operations
less clunky.
Some Links:
Various MSI logging methods: Enable installation logs for MSI installer without any command line arguments
Windows Installer Logging
Related
Context
I created a Github Actions workflow that generates a .msi file that I wan't to execute afterwards to test if the application is working as expected.
The workflow implementation is as below
build-windows:
runs-on: windows-latest
steps:
- uses: actions/checkout#v2.3.4
- name: Create binary from branch
run: |
choco install make
make build-windows
- name: Generate msi
shell: powershell
run: .\.github\scripts\windows\gen-win.ps1
- name: Install msi
run: |
echo "Start Msiexec"
msiexec /qn /i "file.msi" /L*vx!
echo "End Msiexec"
Basically this workflow creates the .exe file (Create binary from branch step), then use a script in powershell that generates the .msi file (Generate msi step), and finally try to install the .msi file (Install msi step).
Issue
The problem occurs on the Install msi step, the runner logs only returns:
Start Msiexec
End Msiexec
... without showing any log, or creating the directories and files as the installation should do on the $HOME directory.
What I tried
Using the default shell for windows-latest runner (which is cmdlet), I tried to run those commands in the workflow without success, using "file.msi" or "path/to/file.msi":
msiexec /i "file.msi"
msiexec /qn /i "file.msi"
msiexec /qn /i "file.msi" /L*vx!
I'm not very familiar with the windows operating system, but for what I searched online, this msiexec command should work.
I also tried to install the .msi file generated manually on a windows 10 computer using those commands with success (so the generated .msi file is valid and working locally). However, it opens another prompt window automatically showing the installation and setup logs (it's not in the same terminal window) and I imagine this may not happen on Github Actions.
Question
➡️ How can I install this application from the .msi file through a command line on the windows-latest runner?
After asking the same thing on the Github Community forum, I got the following answer from #Simran-B (Github Advisory Council Member):
msiexec doesn’t seem to log anything to a terminal. If your MSI does
(even if in a separate window), then it must be something that is
specific to that MSI…
What msiexec supports is to log to a file. Based on Is there anyway
to get msiexec to echo to stdout instead of logging to a file - Server
Fault,
I successfully ran the following PowerShell script (using a Blender
MSI as a test):
$file = "file.msi"
$log = "install.log"
$procMain = Start-Process "msiexec" "/i `"$file`" /qn /l*! `"$log`"" -NoNewWindow -PassThru
$procLog = Start-Process "powershell" "Get-Content -Path `"$log`" -Wait" -NoNewWindow -PassThru
$procMain.WaitForExit()
$procLog.Kill()
I can’t recommend /l*vx!, because the forced flush for every log
line makes things slow and the verbose output with additional
debugging information can produce thousands of lines. Alternatively,
you could log everything to a file without flushing, wait for
msiexec to exit, and then print the file contents to the console in
one go, which should be significantly faster (but you lose live
logging).
If I remember correctly, GitHub-hosted runners use elevated
permissions by default. In my local test, I had to run the above
script from an elevated PowerShell because the MSI tried to install to
C:\Program Files\, which is not writable unless you have elevated
permissions, and that made the installation fail without obvious log
entry. If there’s something wrong with the .msi path, you may get an
exit code of 1619 ($procMain.ExitCode), which is also not very
intuitive. Another possible reason for nothing getting installed (at
least apparently) can be that you don’t actually wait for msiexec to
finish - the command immediately returns and the installation process
runs in the background. You can use Start-Process with the -Wait
option or get the handle with -PassThru and call .WaitForExit() on
it to wait until it is done.
It worked for me! With those commands, I could execute the .msi file to install the software, then use it afterwards in my github actions workflow to perform my tests!
I have a process in UiPath to automate PyCharm, a really simple one like just running a Python script and copying the run message into a text file. Now I want to convert it into a binary file to be executed on a windows machine.
I came to know that UiPath did have an option for exporting projects into executable files but sadly it was also removed.
I also reviewed the orchestrator for UiPath but that does seem meaningful to me. I didn't understand why a company would remove such a crucial feature (conversion to executable) and provide a messy solution like this. May be I'm missing something.
My question is....
Is there any workaround, any third party trick that can convert an UiPath project into windows executable file.
UiPath does not want users to be able to run executables directly. They are forcing users to use Orchestrator. So they always have the full control about the users and their licensing model. If they would still offer the executable way, someone could easily create a Task with UiPath and send this to any other PC without using a UiPath account. So this is mainly the reason they stopped offering this method. But you still have some other options to run your process so don't worry.
Those ways are:
Use Orchestrator. Run process from your Orchestrator dashboard (via Jobs manually or time triggered or even another starting trigger).
Use Orchestrator and use UiPath Robot (comes already with the UiPath installation). Now you can simply start it from tray icon.
Use UiPath Studio and start process from here.
Create a batch file that runs the start command script for your process. This line UiRobot.exe_Path /file:"Main.xaml" will run your process.
Create a Visual Studio application (exe) that runs the batch file from #4.
Use REST API to run the process.
As you can see you have several options but unfortunately the exe workaround is just a wrapper for the batch file.
I would recommend you to use Orchestrator, as it gives you so many possibilities and control on your processes and a good logging.
The simplest way to do this would be to call the UiPath Robot Command Line Interface within a batch file. I suggest that you package the process first and then refer to that package in the batch file using the UiPath.exe execute command with the --process {Package_ID} argument. You can add UiPath.exe to your PATH environment variable so you don't need to use an absolute path to the exe in your batch file. The batch file will be able to run on your Windows VM just like an executable. Alternatively, you could add a shortcut to UiPath.exe and add the arguments to the target of the shortcut in the properties menu of the shortcut.
I'm using AutoHotkey script for this purpose and thought I'd share my method,
Create a *.ahk script using below code,
#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
; #Warn ; Enable warnings to assist with detecting common errors.
#SingleInstance force
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.
SetTitleMatchMode,2
DetectHiddenWindows, On
; you don't need to modify below code unless UiPath Studio changes its shortcut name
EnvGet, LocalFolder, LocalAppData ;use windows Env variable to get local appdata folder
UiPath=%LocalFolder%\UiPath
UiPath_ShrtCut=%A_Programs%\UiPath Studio.lnk
UiPath_Prcss:="UiPath.Studio.exe"
UiPath_Asstnt:="UiPath.Assistant.exe"
FileGetShortcut, %UiPath_ShrtCut%, , OutDir ;get parent directory of shortcut.lnk
;modify your_script_path\Main as per your script and its path
Script=""%OutDir%\UiRobot.exe" "-file" "your_script_path\Main.xaml"" ;script folder and script name
; you can add additional clause in here
If (FileExist(UiPath) "D")
{
Process, Exist, %UiPath_Asstnt%
if ErrorLevel = 0
{
Runwait, %UiPath_ShrtCut%
WinWait, ahk_exe %UiPath_Asstnt% ;wait for UiPath.Assistant to load
Sleep, 2500
Runwait, %comspec% /c TASKKILL /im %UiPath_Prcss% /f ,,Hide ;now kill UiPath main window
;Run, %A_AHKPath% %Rec_Script% ;run record
Run, %comspec% /c %Script%,,Hide
}
else
{
;Run, %A_AHKPath% %Rec_Script% ;run record
Run, %comspec% /c %Script%,,Hide
}
}
return
Then create a task schedule as per your desired trigger and use following in action tab,
Program/Script: "C:\Program Files\AutoHotkey\AutoHotkey.exe"
Add Arguments (optional): "Script_path\Script_name.ahk"
I have created Basic MSI Project for creating installer for my project in Installshield 2014 and it is working fine. I have also created a custom action to execute my exe file while installing the application.
Then i create a Silent Installer using (/s) command line argument. I want to pass the Config file to my MSI setup and one of my Custom Action exe file need this Config file to setup basic project setup.
e.g
Installer.msi /s "c:\project\config.txt"
How to pass this config file parameter to my exe as command line argument?
I have searched in google and existing questions also. I didn't get way to do this.
Till now i didn't get any way to do this. Please anyone help me to do this.
Thanks in advance.
You can pass values to your MSI by command line. This is one way to pass values straight into your MSI, another way is using a transform to modify the MSI. See this answer: Using msiexec.exe custom command lines, or using transform files.
As far as I know there is no limit to how many values you can pass by command line:
msiexec.exe /I "C:\Install.msi" /QN /L*V "C:\msilog.log" STARTAPP=1 FIREWALLRULE="Long string here"
Quick explanation of command line above:
/L*V "C:\msilog.log"= verbose logging
/QN = run completely silently
STARTAPP="1" = Your property indicating the app should be started after install
FIREWALLRULE="Long string here" = Your firewall rule to apply via a custom action
Yes, Glytzhkof is right.
According to your question, you are free to "invent" an own property e.g. CONFIGFILE and pass on the commandline something like CONFIGFILE="C:\myconfig.ini" or something similar.
If the path is always the same (e.g. in SOURCEDIR), you can avoid the whole path and add it in your code, but don't rely on the source for a patch (.msp) for example.
I am not sure if I understand, what you mean exactly with "silent installer".
You can call every msi setup with the parameter "/qn" (or "/quiet") silently. The "/s" parameter does not belong to MSI, but is more common for setup.exe files (bootstrappers) or InstallShield script projects. Of course you can combine a bootstrapper with a MSI called.
For example, using the InstallShield built setup.exe could be something like:
setup.exe /s /v "/qn CONFIGFILE=myconfig.ini"
I am writing a powershell script to uninstall and install a product. Uninstallation and installation process is just clicking on several next buttons with default values populated.
Could you please suggest how to install the MSI file without prompting user for clicking on several next buttons and complete the installation process very quietly.
If I wanted provide customized values during the installation, what could be the process to find out the property names and how to run it silently. Please refer to any references to explore further.
I am using powershell 2.0 and please let me know if further information is needed. Thanks in advance.
Regards,
Kumar
To install a .msi file silently, you should be able to use the /quiet switch with msiexec.
If you need to customize anything, you can set property values like this: PROPERTY=Value
Altogether:
msiexec /i C:\Path\To\File.msi /quiet PROPERTY=Value
To see all the options, just run msiexec without any parameters.
This question is also very similar to yours.
You can do this only if the MSI helps you :). For example, if a property called SERVERNAME is set to FRED in a dialog, then you could say SERVERNAME=FRED on the command line. This assumes that the InstallExecuteSequence that does the work of the install uses just the value FRED. Problems occur when the UI sequence does extra things that won't happen in silent mode because the UI sequence doesn't run in a silent install. If the UI sequence dialogs change SERVERNAME by (for example) adding \ to the front and \MyShare at the end and \FRED\MyShare is used in the execute sequence then you need to know set the command line to SERVERNAME="\FRED\MyShare" because that's what the execute sequence expects. If you don't know all the potential relevant property values you could run the install in UI mode with a verbose log and see them. So in the absence of documentation for silent install you need to reverse engineer it a bit.
If you want to specify what features are to be installed then use ADDLOCAL=comma separated list of feature names.
The basic command line for running silently is (paths truncated):
msiexec.exe /I "C:\WiX.msi" /QN /L*V "C:\msilog.log" MYPROPERTY=1
You can also apply a transform (see explanation below):
msiexec.exe /I "C:\WiX.msi" /QN /L*V "C:\msilog.log" TRANSFORMS="C:\Wix.mst"
/QN: run silently, no GUI during or after the install
/L*V: write verbose log file with all information
MYPROPERTY: set a property at the command line. You can set multiple.
The way an MSI file is supposed to be modified for corporate use is to use a transform file (*.mst).
This is a little "database snippet" that can change the MSI file (which is a database) once applied to it during runtime.
A transform can literally change anything in the MSI, but most often it is used to adjust small things such as removing shortcuts, eliminating undesired runtimes, etc...
A transform is applied to an MSI on the msiexec.exe command line by adding the keyword TRANSFORMS followed by the path to the *.mst file.
You can also uninstall MSI files in a variety of other ways (besides the msiexec.exe command line). Here is a rough guide for how to uninstall MSI files. It includes information on how to uninstall with PowerShell, WMI, VBScript Automation, etc... And there is another post on serverfault.com on the issue of avoiding the use of msiexec.exe to prevent unwanted dialog boxes from popping up during automated runs.
We have an older app from 2006 we'd like to uninstall at the command line using group policy, but I can't get a silent uninstall to work.
This works. Of course I need to click Next to uninstall:
"C:\App\Setup.exe" /uninst
But this does not. I see an hourglass for a couple seconds but the app is not uninstalled.
"C:\App\Setup.exe" /uninst /s
I also unsuccessfully tried some VBScripts. They find the app listed but the uninstall fails. I'm not too familiar with how this process is supposed to work.
You need to create first an ISS response file to silently remove your application,
Create response file :
C:\App\Setup.exe /r /f1c:\app\uninstall1.iss
you will be asked to uninstall, .... and perhaps reply the others windows.
Then your application would be uninstalled and you get a new response file c:\app\uninstall1.iss
Next, if you want to remove silently this application on another computer :
launch : C:\App\Setup.exe" /s /f1c:\app\uninstall1.iss
For more information see:
http://www.itninja.com/blog/view/installshield-setup-silent-installation-switches
Best Regards,
Stéphane
Try this, with the original setup.exe version that was used to install
"C:\App\Setup.exe" /x /s /v/qn
I've been struggling with the silent uninstaller for a while, and finally came to a solution that works for me in most cases, both for InstallShield v6 and v7.
1. First (as it was mentioned above), you have to generate an InstallShield Response file (e.g. uninstall.iss). In order to do that you have to launch your setup.exe with parameters:
> setup.exe -x -r -f1"C:\Your\Installer\Location\uninstall.iss"
This will go through the normal uninstall wizard and generate a Response file for you: uninstall.iss
2. Then, before trying your silent uninstaller, I guess, you should re-install the software.
3. And finally, run your silent uninstaller playing back the recently generated Response file:
> setup.exe -x -s -l0x9 -ARP -f1"C:\Your\Installer\Location\uninstall.iss"
That's it.
Now, a few important notes:
Note 1: I'm working with a 3-rd party installation package that I didn't build myself.
Note 2: I use dashes (-) instead of slashes (/) to define parameters. For some reason it doesn't work with slashes for me. Weird but true.
Note 3: The -ARP and -l switches are required for some installation packages to manage the software removal from the Add/Remove Programs list and to preset the default input language accordingly.
Successful silent uninstallation is all about the correct parameters!
So keep exploring, the correct parameters vary depending on a specific package and installer version.
I hope my input was helpful.
Try
Format: Setup.exe M{Your Product GUID} /s /f1[Full path]\*.iss for creating the ISS file for uninstallation.
From Stephanie's sample, I think it's missing the GUID.
There's a good link at the developer's site # Creating the Response File.
Try it out n tell us,
Tommy Kwee
I struggled with this for a long time so posting it here in case anybody else stumbles upon it.
If you happen to have an installer which uses the legacy Package-For-The-Web format then you need to use the parameter -a to pass additional parameters to the extracted setup file.
Record (un)installation files (click through the installer manually):
.\DWG2PDF2019.exe -a /r /f1"c:\app\dwg2019_install.iss"
.\DWG2PDF2019.exe -a /r /f1"c:\app\dwg2019_uninstall.iss"
Silently (un)install:
.\DWG2PDF2019.exe -s -a /s /f1"c:\app\dwg2019_install.iss"
.\DWG2PDF2019.exe -s -a /s /f1"c:\app\dwg2019_uninstall.iss"
Source: https://help.hcltechsw.com/caa/3.0/topics/appacc_silent_install_t.html
There's another way to uninstall an app by searching for it in the Registry, and using the UninstallString (this sample code uses powershell on windows 10):
# Get all installed apps from Registry
$Apps = #()
$Apps += Get-ItemProperty "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*" # 32 Bit
$Apps += Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*" # 64 Bit
# Uninstall My App
$my_app = $Apps | Where-Object{$_.DisplayName -eq "The Name Of My App"}
$uninstall_string = " /C " + $my_app.UninstallString+' /S'
Start-Process -FilePath "cmd.exe" -ArgumentList $uninstall_string -Wait
if you don't know the exact full display name of your app, you can print the "Apps" array to a file, and search there:
$Apps | Out-File C:\filename.txt
I was working on a silent uninstall of an InstallShield installer and was running into similar issues. What was posted here did not work or help. After lots and lots of trial and error I did find that for some reason when I used the -uninst option for both the creating the response file and running the silent uninstall I had success. In case anyone runs into a similiar issue and stumbles upon this thread I wanted to share. I am not sure why but adding -uninst did change the contents of the response file.
In my example creating response file: "C:\Program Files (x86)\InstallShield Installation Information\{0D20ACF2-CEE1-4523-BFCF-389BC4CC81FB}\setup.exe" -runfromtemp -l0x0409 -removeonly -uninst -r -f1"c:\uninstall.iss"
Then I could finally get the silent uninstall to function as expected: "C:\Program Files (x86)\InstallShield Installation Information\{0D20ACF2-CEE1-4523-BFCF-389BC4CC81FB}\setup.exe" -runfromtemp -l0x0409 -removeonly -uninst -s -f1"c:\uninstall.iss"