I have run this custom action with Installshield Limited Edition for Visual Studio in the past and it has worked. But now when I try this with Installshield 2016, this custom action gives me a 1722 error and rolls back the installation. The log file doesn't give any more detail than "failed with error 1..." and the 1722 error.
My custom action setup via the Wizard -
Working Dir: InstallDir
FileName & Command Line: "[SystemFolder]cmd.exe" /c "[INSTALLDIR]somefilename.exe" "'%r' '%keyname=keyname' '%keydll=some.dll' '%appexe=[INSTALLDIR]differentfilename.exe'"
What this is supposed to do is run somefilename.exe from the command line, with parameters "%r", "%keyname", "%keydll" & "%appexe".
When I run it on the command line directly so -
"C:\Program Files (x86)"\somefilename.exe "%r" "%keyname=keyname" "%keydll=some.dll" "%appexe=C:\Program Files (x86)\differentfilename.exe" - it runs fine.
I think I am missing some quotes someplace and I have tried various combinations with no luck.
Any ideas what I am doing wrong?
Thanks in advance!
Thanks for the suggestions #PhilDW.
I could possibly take out the cmd jacket and just run the exe and try.
I finally got it working though, by changing some quotes etc. Here's what the final FileName & Command Line argument looks like:
"[SystemFolder]cmd.exe" /c start "" /d"C:\Program Files (x86)\foldername\" "somefile.exe" "%r" "%keyname=something" "%keydll=something.dll" "%appexe=C:\Program Files (x86)\otherfilename.exe"
Hope this helps someone.
A few suggestions:
You should post the verbose MSI log section relating to this because it should show the complete resolved command line, assuming that you have created a full verbose log and not a partial log.
It's not clear why you need to run this program with a cmd jacket. If it's a plain Windows program just run the executable as a custom action.
When you run from the interactive user explorer shell you get some infrastructure (such as working directory) that you do not get with a custom action started by an msiexec.exe process. This matters because you have not specified an explicit full path to some.dll, so it's not obvious it can find the file.
It might be useful to say something about where this custom action runs and its type. For example if it's turned into an immediate custom action (all VS custom actions are deferred) then it will fail because no files have yet been installed. Likewise, if it's deferred but somehow before the InstallFiles standard action it will fail.
All custom actions run by Visual Studio generated projects are deferred and run with the system account in a per-system "Everyone" install. If your custom action requires elevation then it must also be deferred and the MSI must show a UAC elevation dialog, because otherwise it may well run but fail with access errors. It may have become a non-elevated per user install.
I am attempting to run a JScript script using Windows Script Host 5.8 on a 32-bit Windows 7 PC. This script is part of a larger build effort for an open source software project, where an ActiveXObject is being created as part of the script. This has failed to run, but I suspect that the specific script is not at fault, but rather my local Windows Scripting Host (WSH) setup.
I have inferred this based on the following 'bare bones' tests that I have run with a one line test script:
I prepare a script using Notepad which is saved as 'test.js' and contains the following line:
var strLit = "This is a string literal.";
I then execute the above script using the following command:
cscript /e:jscript test.js
This seems to run successfully, of course returning no output, but critically no error message.
I then change the script to contain just the following line:
print("Hello World!");
When run with the same command as above, the following error message is received:
Microsoft JScript runtime error: Object expected
I then change the script to contain just the following line:
var fso = new ActiveXObject("Scripting.FileSystemObject");
When run with the same command as above, the following error message is received:
Microsoft JScript runtime error: Automation server can't create object
It is this third version of the script that contains the line failing in the open source software script mentioned above. However, based on the creation of a string variable script succeeding, I would infer that WSH is to some extent functioning. However, the fact that the 'hello world' script has failed, as well as the failure of the ActiveXObject would indicate that WSH with the JScript engine may not be correctly set-up on my computer or otherwise functioning.
I would also infer that this likely has nothing to do with Internet Explorer security levels due to this script being run from the command line with no link to Internet Explorer.
I have done the following to try to resolve this problem:
Ensured that Windows associates files with extension '.js' with WSH, although by using the '/e:' switch when calling the script as above, this is not an issue anyway.
Re-registered scripting components on my computer using an administrator elevated command prompt with the following commands:
regsvr32 %systemroot%\system32\vbscript.dll
regsvr32 %systemroot%\system32\jscript.dll
regsvr32 %systemroot%\system32\dispex.dll
regsvr32 %systemroot%\system32\scrobj.dll
regsvr32 %systemroot%\system32\scrrun.dll
regsvr32 %systemroot%\system32\wshext.dll
regsvr32 %systemroot%\system32\wshom.ocx
All of the above commands work successfully, except for the last two, where the following errors are received:
The module "C:\Windows\system32\wshext.dll" was loaded but the call to DllRegisterServer failed with error code 0x80040201
The module "C:\Windows\system32\wshom.ocx" was loaded but the call to DllRegisterServer failed with error code 0x80040201
Attemped to run the script with my virus protection (F-Secure) completely disabled and there being no internet connection.
I would infer the following from the tests above:
Script one: This is a simple script declaring and initializing a variable and doing nothing else, meaning that it is no surprise that it should run and perhaps confirms that the JScript engine is at least present and working fundamentally.
Script two: This is again a simple script but that may make use of additional functionality (I. e. 'print').
Script three: This is a simple script, but seeks to create an object of a specific type, by means of recourse to an application (identified as 'Scripting') to achieve this. This 'Scripting' application is supplied as a parameter when creating a new ActiveXObject which in the Microsoft JScript reference is identified as a 'servername'. Generically, the 'servername' is defined by the Microsoft JScript reference in this context as being 'the name of the application providing the object'. I note that the error message for script three makes reference to an 'automation server' and therefore wonder if there is a link here.
Would anybody have any ideas as to what may be the problem here, specifically with script three? The error message in script three above has been widely discussed online in the context of Internet Explorer security levels, but due to this being a script run on the command line, I cannot see how this solution would relate this problem.
Any ideas would be much appreciated.
Thanks
Jason
When I create a new WebAPI project (MVC4) I get the following error.
EntityFramework.5.0.0: Failed to initialize the Powershell host. If your powershell execution policy setting is set to AllSigned, open the package manager console to initialize the host first.
jQuery.1.7.1.1: Failed to initialize the Powershell host. If your powershell execution policy setting is set to AllSigned, open the package manager console to initialize the host first.
After Googling I have found a few answers but nothing that works yet.
Error creating new MVC project - EF and JQuery
This answer seems like it should work for me as my last project was a 7z Command Line app and I might have done something daft with 7zip. But I copy pasted the 7-Zip directory from Program Files to Program Files (86) with no luck.
http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/c934fed4-e44e-4a06-9e3b-eccb9c8aa8d6
There is an answer here that might work (I haven't tried it) but even if it does work I wouldnt want to do this every time I create a new project.
Is anyone able to help me with this one?
I got around a similar error by running PowerShell as administrator with the command Set-ExecutionPolicy Unrestricted, restarting Visual Studio, and opening the Package Manager Console before what I wanted to do.
Make sure you understand the security implications of doing this first.
http://technet.microsoft.com/en-us/library/ee176961.aspx
Restricted - No scripts can be run. Windows PowerShell can be used only in interactive mode.
AllSigned - Only scripts signed by a trusted publisher can be run.
RemoteSigned - Downloaded scripts must be signed by a trusted publisher before they can be run.
Unrestricted - No restrictions; all Windows PowerShell scripts can be run.
I encountered this issue recently, after re-install VS and install the latest VS update 2, things go well. This works for me at least.
I am attempting to install PostgreSQL 9 (postgresql-9.0.3-1-windows.exe) on my WinXP machine and get the following error at the start:
Some googling around yielded some advice that suggested Windows Scripting Host might be disabled. I've checked and WSH is definitely enabled, so it must be something else. Question is, what?
I can see a file called prerun_checks.vbs is created in %TEMP% and when I try to run this manually, I get the following:
Which looks like a permissions error. However, I am an Admin, and I've given myself full control of the temp folder and it's still not working.
Any help appreciated.
In my case the solution was related to NotePad++ being the default application for opening .vbs files. If you have the same situation, here's an elaborate solution:
http://igordcard.blogspot.co.il/2012/03/unable-to-write-inside-temp-environment.html
In a nutshell, in the registry, you need to go to HKEY_CLASSES_ROOT\.vbs, and set the (Default) entry back to the string VBSFile.
This is a an old thread, but I just had the same problem on windows 10:
Unable to write inside TEMP environment path
Solve by the following steps
Check that the problem is related to Windows Script Host.
From cmd run wscript.exe
If you get an error Windows Script Host is not enabled then you can solved it by running the following from cmd
Fix for Current User
REG DELETE "HKCU\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Fix for Local Machine
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Now you can install psql
As I was finishing off my question above, our IT chap turned up and knew what the problem was immediately: it's McAfee. It prevents anything from running in a TEMP folder, including Windows Scripting Host scripts. Disabling McAfee for the duration of the installation fixed the problem for me.
So if you see this problem, try disabling your anti-virus.
The answer in the following page helpped me.
http://forums.enterprisedb.com/posts/list/3040.page
run-> regedit and take backup of registry using export
HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8} -> InprocServer32
Modify registry entry with new value as C:\Windows\System32\vbscript.dll
In fact, I found there are 3 entries of HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8}, and set the first one as above, it works.
If anyone else is searching for information on this and doesn't have any luck here, you might want to look at:
http://wiki.postgresql.org/wiki/Troubleshooting_Installation
For follow-ups to the mailing list please read:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Well, in my case nothing worked, and disabling McAffee needed a special ticket with my company's security team to actually do... so I installed using the binaries, by following this guide Helpful Guide.
In summary, download the binary from here, unzip it, go inside the pgsql folder, create log and data directories in there, and then open a command prompt, navigate to where the pgsql\bin folder is, and run initdb -U postgres -A password -E utf8 -W -D POSTGRESQL_ROOT\data
You can start and stop the server by running
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" start
and
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" stop
where POSTGRESQL_ROOT is the full path to the pgsql folder.
All the above did not work for me. I was getting an error like:
Script output:
CScript Error: Windows Script Host access is disabled on this machine. Contact your administrator for details.
so after a couple of googling i found the solution:
Navigate to the following key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings
In the right panel, you will see Enabled. If you see the entry 0, it means that the Windows Script Host access is disabled on your Windows machine.
Double Click on it and give it Value Data 1 to enable it.
A value of 1 will enable Windows Script Host
A value of 0 will disable Windows Script Host.
for windows 10 navigate to
HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings
To prevent further problems you should also exclude the data directory (where Postgres puts its data) from being scanned by your virus-scanner
In my case it was another application that caused the problem. Not Notepad++. To others who encounter this problem, you can diagnose it by first deleting all files in C:\Documents and Settings\UserName\Local Settings\Temp so that you'll be able to find the bitrock_installer.log easily when you try installing postgresql again and view the instructions in it. Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it.
I had this issue when trying to install the 32 bit version on Windows 7 64 bit.
Trying the install kit for 64 bit presented no errors, but the solutions presented by others are also valid.
In my case I've downloded McAfee removal tool
MCPR (McAfee Consumer Product Removal)
which cleaned up some tailings after McAfee uninstallation.
Some registry entries which previously had InprocServer32 values like 'c:\program files\common files\mcafee\systemcore\...' changed back to its original values:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = C:\Windows\SysWow64\vbscript.dll
After that I successfully installed PostgreSQL 9.3
it happens when Notepad++ associates .vbs file types.
you can open notepad++ -> Preferences -> fileAssociation
Remove the .vbs from the registered exts.
Close the notepad++. Try installing Postgres again.
In my case Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it. BlueFish is grab .vbs file association.
In the temp directory, my bitrock_installer.log file had the following:
Executing cscript //NoLogo "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs"
Script exit code: 1
Script output:
Input Error: Can not find script file "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs".
Turns out that Windows has a symlink between the following directories:
C:\Users\cpetrie\Local Settings\Temp
C:\Users\cpetrie\AppData\Local\Temp
For some reason my "TMP" and "TEMP" user variables were referencing the "Local Settings" path instead of the "AppData" path. Changing this fixed my install issue.
My problem was Smad-Av which disables Windows Scripts from running,
Only after going through this thread i remembered.
I just right clicked the Smad-Av icon and selected Allow Windows-Script & Office-Macro (Permanent).
I had the same problem with installing PostgreSQL (Unable to write in TEMP environment variable path), the problem was in Windows Script Host which was disabled (check the log file to see if this is your problem). enable it with register editor (run-->regedit) at this location Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings by setting its value at 1
For more details check this web link: http://1stopit.blogspot.com/2011/01/postgresql-83-and-84-fails-to-install.html
I had the same problem in Windows 10 and the culprit was the OS's permission, or rather the lack thereof, on allowing the executable to write on the User dedicated Temp folder.
Solved it by following my gut and changing the User Temp folder to the same with the system's : Win + Pause/Break to have the Computer Properties window appear (you can do that manually by right-click on Computer icon on Desktop -> Properties) -> click on Advanced System Settings on the panel on the left -> click on Environment Variables and
under "System variables" - Variables, find the TEMP and TMP ones and copy their paths. Then, under "User variables for Administrator" - Variables, find the TEMP and TMP ones and paste the paths. It's most always "C:\Windows\TEMP" anyways ;)
There's this site I read : https://www.askvg.com/where-does-windows-store-temporary-files-and-how-to-change-temp-folder-location/
search for "Registery Editor" and run it.
choose HKEY_CURRENT_USER => SOFTWARE => Microsoft => Windows script host => Setting (Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows Script Host\Settings)
open "Enabled" and change value data to "1".(you will find it with a vlaue of 0).
Happy coding!
Check the log in the system's TEMP directory (provided the installer is able to write into it).
There's lot of information about the errors.
My issue was that VBS files were associated with a text editor (probably the anti virus software is the culprit) .
Here you can find some reg edit scripts to revert to the default behaviour:
http://www.nilpo.com/2009/07/windows-xp/restoring-vbs-vbscript-script-file-file-associations/#more-107
Cheers
My solution is similiar to #5, with an Explantion of how and why McAfee ruins your vbscript registration.
Apparently, when I had McAfee antivirus software on my computer, it bashed the vbscript.dll registration that Windows Scripting Host needs to run .VBS files.
In the exported .REG file:
[HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
#="C:\Program Files\Common Files\McAfee\SystemCore\ScriptSn.20120327211246.dll"
That SHOULD be changed back to "C:\Windows\System32\vbscript.dll" now.
McAfee apparently installs a DLL that hijacks the vbscript.dll in order to try to protect bad scripts from running. When I uninstalled McAfee in favor of Microsoft
Security Essentials, McAfee did not restore the registry paths ("not
my problem"), and the McAfee DLL, of course, was removed from the location during uninstall, so the vbscript.dll registration in fact pointed to NOWHERE and NOTHING.
There has to be a better way to write Antivirus software so that it doesn't disable the user's operating system when it is uninstalled, or when features
are turned off, or replace registration. See the following:
https://kc.mcafee.com/corporate/index?page=content&id=KB71660
I have a 64-bit OS. The registry path was changed in a number of locations.
The regular class ID should point to the "C:\Windows\System32\vbscript.dll" 64-bit file.
The "Wow6432Node" registry paths should point to the "C:\Windows\SysWOW64\vbscript.dll" 32-bit file.
Yes, the 64-bits are in the "32" folder and the 32-bits are in the "SysWOW64" folder. Microsoft didn't want to change the name of the main "System32" execution folder when it migrated to 64-bits.
HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_CLASSES_ROOT\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
Before you start messing with the registry, check if WSH is actually disabled or not. To do that run wscript.exe in the DOS box.
If you see a dialog box called "Windows Script Host Settings", WSH is enabled, and your problem with PostgreSQL installation must be related to something else.
If you get an error box that says "Windows Script Host access is disabled on this machine. Contact your administrator for details", WSH is disabled, and your problem with PostgreSQL installation may be related to it (or may be not).
For me, my problem was related to Windows script. I resolved this by right-clicking on smadav icon in the hidden icons in the task bar and checked "Allow Windows-script and Office-Macro (Permanent)". Then double click on the PostgreSQL setup again.
First go to registry Editor then choose HKEY_CURRENT_USER > software > Microsoft > Windows script host > setting > default > add value data to 1 and click Ok. done!
After disabling Smad Av, it still did not work. So, I right clicked on the Smad Av tray icon and I selected 'Allow Windows-Script & Office-Macro (Permanent)' and it worked.