I'm trying to get a log from my install that uses a setup.exe. I can get a log with just setup.exe /V"/l\*v c:\temp\installlog.txt", but I want to pass the x parameter as well to get "Extra debugging information" and when I try setup.exe /V"/l*vx c:\temp\installlog.txt" I get:
1629: Invalid command line.
Any idea what I'm doing wrong? I have msiexec version 5 installed.
Ancient setup.exe: I tried with an ancient version of Installshield and the setup.exe for a Basic MSI worked as expected. I could pass in Setup.exe V"/L*v C:\Test1.log" and Setup.exe V"/L*vx C:\Test1.log" - both command lines worked and the resulting log files were different with the x adding more verbose nonsense :-). Verbose indeed.
Modern Suite Setups: I tried with InstallShield2018Premier.exe - a recent installer from Installshield, and it failed with that command line. I am pretty sure this latter file is an Installshield Suite setup.exe - it has to be. These suite setup.exe files (or whatever they are renamed to) are not the same as the setup.exe files generated for a single MSI file. There are some details about this here (just my observations, needs verification): Regarding silent installation using Setup.exe generated using Installshield 2013 (.issuite) project file.
So I guess the first thing I would verify is that you are not using a suite setup.exe (as opposed to a regular setup.exe launcher). However, it does look like the command line without the x parameter did work for you, and then this theory doesn't make any sense. Posting anyway in case you tested with another setup.exe or something like that. There could also be changes to the regular setup.exe which makes it fall over on the x now, but it worked in earlier versions.
Since the above does not seem like a real answer, how about some longshot suggestions?
Did you try to disable your anti-virus while running with this switch? Just to rule this out in case the x initiates something funky.
Did you try and verify similar results on another computer? Maybe a virtual machine? (a very basic, clean one).
Is this an Installscript MSI? I would build a Basic MSI wrapped in a test setup.exe to see if the behavior is the same for a vanilla MSI file.
All I can think of at the moment.
UPDATE: OK, a couple of things.
Installscript MSI projects are very buggy in my experience. I would use a Basic MSI if at all possible. The resulting MSI files are also much more compatible with corporate deployment requirements.
Maybe Try This: It is possible that you can "hack" the compiled Installscript MSI setup to be able to install without the setup.exe wrapper. So you extract the files with an admin install going setup.exe /a and then you use this trick: How to deploy the Installshield MSI without having to run Setup.exe - in order to run the extracted MSI file using the normal msiexec.exe engine. So then you just go msiexec.exe /i MyMsi.Msi /L*Vx C:\Test.log /QN and see what you get.
It is also conceivable that there is a setting in Installscript MSI projects where you can directly specify a command line to pass to msiexec.exe for testing. I have no access to recent Installshield version and can not help you with this. Documentation might give you a clue.
Have you tried this?
setup.exe /s /v"/lvoicewarmupx! C:\temp\install.log"
Related
We have an installer for our application. (A C++ program, created in VisualStudio 2012.) The installer is now signed and require elevated privileges - the user gets a neat UAC question.
For some customers though, the installer needs a lot of other files. We use IExpress to create a self-extracting archive. The user runs the self-extracting EXE file, the files get unpacked and our installer starts.
But that doesn't work after we added UAC support. The EXE built by IExpress won't start a program that requires elevated privileges.
An easy solution would be that the EXE built by IExpress also requires elevated privileges. But I haven't found a flag to IExpress that does that. (Or did I miss something?)
Is there an easy way to add the "require elevated privileges" to an existing EXE file?
A fairly easy way to do it seems to be via cmd.exe. Just change your install program from, eg:
setup.exe
to
cmd /c setup.exe
Then the IExpress “magic UAC detection” won’t happen, and the user will get the standard UAC prompt when your program runs.
If you want to know more…
New versions of IExpress include a manifest which deliberately does not request UAC elevation for the IExpress-generated package itself. Here’s what it looks like in wextract.exe (the part that is actually bundled in your generated package):
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
According to MSDN, the asInvoker level means: The application will run with the same permissions as the process that started it.
Apparently there are some programs which can modify the manifest after-the-fact. One is called ResEdit, though I recommend that you download it from SoftPedia, as the .net site seems to carry some adware now. I didn’t have any luck with it (I think because I didn’t have Visual Studio installed) but maybe it will work for you.
If you decide to go this route, try to change the level to requireAdministrator.
you could try this in the post installation command of iexpress wizard:-
PowerShell -windowstyle hidden -command "Start-Process -Wait setup.exe -Verb Runas"
-windowstyle hidden hides the powershell window.
-Wait waits for the completion of setup.exe before deleting temp files(where iexpress files are extracted by default)
-Verb Runas Requests for elevation.
If you right click the installer exe file, go to Properties and click Compatibility then check the check box called Run this program as a administrator and click OK it should work.
I am doing an upgrade for the existing exe file using installshield. when installing the update , in files in use dialog I select the option to automatically close and restart the application instead of the other option to reboot the system.
But I get an extra window which tells me to restart the system again after installation is complete. How to disable this window? Please help :)
You can try to run the installation silently with REBOOT=ReallySuppress (update the paths). Please note that I haven't had the chance to test all these command lines:
msiexec.exe /I "C:\IsWiX.msi" /QN /L*V "C:\msilog.log" REBOOT=ReallySuppress
/I is for install
/QN is silent mode
/L* is verbose logging
If you have an EXE file instead of an MSI file I would extract the MSI to an administrative image (file extract from setup.exe basically) using the following command:
setup.exe /a
Then specify an extract location for the files in the EXE file. You can also run it directly with the Installshield command lines for EXE files. Something like:
Setup.exe /v"REBOOT=ReallySuppress /qn"
Or silently with logging:
Setup.exe /v"/l*v c:\test.log REBOOT=ReallySuppress /qn"
There are also some simplified command line macros from Microsoft. Most of the time these can be used. Other times you need the full command line interface.
I'm setting up our build server. I've installed Jenkins on a Windows 7 machine and am running into problems when building the 64 bit version of our solution.
We're using Visual Studio 2012 Express for Windows Desktop. Jenkins uses the MSBuild plugin and is targeting the 64 bit MSbuild exe at
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe
However, when it runs msbuild an evironment variable is not being parsed properly. VCTargetsPath.
If I leave everything as-is then the output of MSBuild is this
error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I played around a bit with the VCTargetsPath variables in the registry, Windwos Environment Variables and as Jenkins Eviornment Variables too. I noticed this behavior.
If I set VCTargetsPath to be "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110" then the output of msbuild is the same as above. However, if I set it to "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0" then the output changes to this.
error MSB4019: The imported project "C:\progra~2\MSBuild\Microsoft.Cpp\v4.0\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
The tile Microsoft.Cpp.Default.props is found in "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110" I checked the limits on environment variable length and it's supposed to be 2048 characters. Am I missing something obvious here? I've found some info that basically says I am going to have to reinstall everything in a specific order, which is quite annoying (but also very Microsofty).
I fixed this by adding
/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"
or the more elegant
/p:VisualStudioVersion=12.0
into
Build > Build a Visual Studio project or solution using MSBuild > Command Line Arguments
Your first round of fix-it attempts for a build server.
Install the appropriate SDK on the build machine.
http://www.microsoft.com/en-us/download/details.aspx?id=8279
If that doesn't work, report back.
EDIT:
/p:VisualStudioVersion=11.0
Add that to your command line...as a parameter for msbuild.exe
EDIT:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
I have a 64 bit version of msbuild.exe there.
Which isn't what you show.
I'm throwing a guess out, nothing concrete, FYI.
Try passing : /p:PlatformTarget=x86 as one of the arguments to MSBuild.
I've been trying to get node.js installed on my home PC for a while now with no luck. I've tried different versions for the past couple months and no matter what I try it starts rolling back the install at "Creating shortcuts" and it fails to install. I created an install log for anyone who wants to look at it and take a stab at helping me solve the problem. Thanks!
https://dl.dropbox.com/u/177486/MSIf99e3.LOG
I have faced the same problem, I have resolved my issue. I just mark performance counter to Install when required during installation of node.js
Windows Installer is reporting that it's installed even though it's been rolled back.
Run msiexec /x {29552F29-7FE9-441F-BC56-E6B591587A59}
Where the above guid is the ProductCode value from your log.
If that doesn't work and you have access to Orca.exe from the Windows SDK, you may be able to modify WixSchedInternetShortcuts to a false condition and install successfully. To do that, install Orca, then right click on the node.js msi file and choose 'Edit with Orca' then:
Highlight InstallExecuteSequence under "Tables" on the left.
Find WixSchedInternetShortcuts in the right
Double-click the Condition cell and change VersionNT > 400 to 0
Go to File -> Save
Run the installer again
After installing this version, you should be able to cleanly remove it via Add/remove programs and install another version without modifying the msi file.
I had the same problem with v0.10.35. (23 Jan 2015)
All I had to do was disable the shortcuts in the custom install pane and it worked fine:
My solution
You must install each item separately.
Npm package manager
Add to path
Online documentation ...
Nodejs runtime / Performans counter
(İmportant) nodejs runtime / Event tracing(etw) (select"feature will be installed be required"
restart computer
Last install view
All above methods do not work.
-running msiexec as admin
-msiexec /x ...
-modifying WixSchedInternetShortcuts
-dropping the row WixSchedInternetShortcuts
-even this: removing the option of creating shortcut to online documentation during the installation
Might manually fix it, you can read this help to install product and then add C:\Program Files\nodejs Path to Windows Environment variables.
Open the command promt and paste the below comman
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib_V2Providers{793c9b44-3d6b-4f57-b5d7-4ff80adcf9a2}" /s
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib_V2Providers{1e2e15d7-3760-470e-8699-b9db5248edd5}" /s
If you get a result for the command , go to the registry key and delete that key. Now try to install it again. You should be able to install it now.
msiexec /i node.msi /qn+ ADDLOCAL=ALL REMOVE=NodePerfCtrSupport,NodeEtwSupport
This might help
Had the same problem. Solution 1 provided by Jim Schubert did not fix it. I then used Orca to edit the installation file. Changing the VersionNT condition also did not fix it for me. I then just dropped the rows from WixSchedInternetShortcuts and it installed successfully. I guess it had some problem with writing the shortcuts. I had also previously tried running msiexec as admin ("/a" option), but this didn't fix it...
One point to be aware of (I learn it the hard way): even after having edited the installer with Orca, don't try to uncheck the checkboxes for shortcuts creation in the installer, leave them checked or it will fail with the same error message.
It happened to me as well, I removed almost everything from the installation and completed the installation. After that I ran the installation again and added one by one until I installed all.
You can always use chocolately install:
https://chocolatey.org/packages/nodejs.install/8.11.1
choco install nodejs.install --version 8.11.1
Check if Avast Antivirus is installed in your machine.
If it is turn off the shields and try installing nodejs
Now it works completely fine...
I have a third party application I would like to silent install from the command line.
The application is PPLive available at: http://www.pptv.com/en/
It is an NSIS installer, and currently when silently installed, installs toolbars, and additional pieces of software, launches on completion etc.
Without repackaging it, how do I control the checkbox options on the pages of the normal installer from the silent command line install.
Is it even possible?
NSIS supports the silent install option with the /S command line script, however, it only sets a flag that the install script can check:using IfSilent.
There is an example script here that demonstrated a silent installation.
You can't control the components unless the installer has been coded specifically for it (By using a "answer" file/.ini or some parameter you pass on the commandline) NSIS itself only allows the author of the installer to know if it is in silent mode or not, the rest is up to them. You would have to ask the PPLive people about it (Or request that they add it if they don't support it already)