In my MSI project, I require an .exe to be ran immediately after installing the product. The .exe comes with the product files. So I used a Custom Action to define this .exe to be run.
In the Custom Action Wizard:
TYPE = LAUNCE AN EXECUTABLE
LOCATION = INSTALLED WITH PRODUCT
SOURCE = Service.exe
TARGET = [FOLDER_BEING_INSTALLED]Service.exe
RETURN PROCESSING = SYNCHRONOUS(CHECK EXIT CODE)
IN-SCRIPT EXECUTION = DEFERRED EXECUTION
INSTALL EXECUTE SEQUENCE = AFTER INSTALLFILES
During installation using these settings the .exe does run, but it runs during the installation load screen and causes the installation to lock up and not finish.
Related
I'm wondering how to start "Xilinx SDK Eclipse GUI" (XSDK) directly from the command line?
Currently, I'm launching XSDK by first launching "vivado", and then going to the "File->Launch SDK" menu. However, this is a bit cumbersome to always open Vivado first, just to open "Xilinx SDK". What I want to do, is launch "Xilinx SDK" directly from my Git bash Shell under windows 10 and then open the previous project under "project_1.sdk" and to continue with what I was working on last time.
My Git Bash Setup:
#~/.bashrc:
export PATH=/c/Xilinx/Vivado/2017.3/bin:$PATH
export PATH=/c/Xilinx/SDK/2017.3/bin:$PATH
Then:
$ xsdk -workspace your_project_dir.sdk &
Also:
$ xsdk -h
Display Options:
-help
Help -- just display this message and quit.
-version
Display Version and quit.
-batch
SDK Tcl Batch Mode.
-wait
Wait for SDK to complete.
Options:
-workspace <Workspace location>
Specify the Workspace directory for SDK projects
-hwspec <hardware specification file>
Specify the XML file to load.
-bit <bitstream file>
Specify the Bitsteam file to use for programming FPGA
-bmm <bmm file>
Specify the BMM file to use for BRAM initialization
-batch -source <tcl script file>
Specify tcl Script file to executee all commands in SDK batch mode
{-lp <repository_path>}
Add <repository_path> to the list of Driver/OS/Library search directories.
-eclipseargs <eclipse arguments>
Any other arguments that should be passed to Eclipse.
This should follow all other SDK arguments.
-vmargs <java vm arguments>
Any other arguments that should be passed to Java VM.
This should follow all other SDK arguments.
Also useful:
SDK Command Line Batch Mode
The Eclipse/SDK can be launched in these two other ways
(1) Launch from the Vivado TCL Command Line:
Going from Vivado to SDK often has these steps
- File > Export (Hardware)
- File > Launch SDK
Each of these commands prints information in blue text in the Tcl Console.
Those commands can be copied into a tcl script and run from Tcl Console.
By default Tcl runs from this folder
C:\Users\WinUserName\AppData\Roaming\Xilinx\Vivado
If the script is placed there (e.g. zz1.tcl, or just zz1)
Then it can be run from the Tcl Console as
source zz1.tcl
That will execute the commands in zz1.tcl -> export hardware and launch the SDK
(2) Or, run Eclipse/SDK from Windows, then select the SDK folder:
The SDK can be run directly and can be found here:
C:\Xilinx\SDK\2019.1\bin\xsdk.bat
When it runs it will ask for a Workspace
Click [Browse] and navigate to the .SDK folder in the Vivado project
It will open and run as usual, without Vivado running, etc
Note: I have noticed that Vivado/SDK can be temperamental about how and when project folder contents are changed. Including if the SDK is launched and another SDK is already running in that folder. In some cases, the easiest recovery is to rename the ~corrupt SDK folder, create a new HelloWorld project, get HelloWorld running, and then update files into the new folder.
Trying to uninstall a software using the uninstall string (and running that with Exec in InitializeSetup) before installation, it doesn't wait for the un-installation to complete but proceeds to the next step of installation in Inno Setup.
I am using the following code and the software I am trying to un-install in an Installshield product:
Exec(
ExpandConstant('{pf}\InstallShield Installation Information\{{XXX8X88X-XX8X-88X8-X8XX-88X888X88888}\setup.exe'),
'-s -runfromtemp -l0x0004 -removeonly -remove', '',
SW_SHOW, ewWaitUntilTerminated, ReturnCode)
The setup.exe most probably executes a subprocess for an actual uninstallation and exits itself. So Inno Setup seemingly does not wait for the process to finish. This is a common behavior, as the uninstaller needs to delete itself, what it cannot do, if it still running. So it creates a copy of itself (or another executable) in a temporary folder and (re)executes from there.
As per InstallShield documentation, you can try adding /w or /Clone_wait switches to the command-line:
/w ... For a Basic MSI project, the /w option forces Setup.exe to wait until the installation is complete before exiting.
/Clone_wait ... This parameter indicates that the original setup should wait for the cloned setup process to complete before exiting.
I develop/maintain an installer built with InstallShield that supports multiple instances. Due to various reasons we always recommend those who run our installer to use the /Instance switch that InstallShield's setup.exe bootstrapper has. Is it possible to get InstallShield to require that the /Instance switch is used? Or is there anyway to check if the setup.exe has been run without the /Instance switch?
If this is an Install Script installer, you can check the value of the command line parameter when the installer first starts. If the value of the command line parameter is not what you want, you can display a messagebox to the user and exit.
szCommandLine = CMDLINE;
if (szMasterCommandLine == "/instance") then
MessageBox("Hello! This installer is running in instance mode.", INFORMATION);
else
MessageBox("You must run this installer with the /instance command line parameter.", INFORMATION);
abort;
endif;
I have created a Custom Action named UninstallDokan,which Dokan is driver for my software.I encounter the errorwhen I uninstall my program:
Error 1721:
There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action:UnistallDockan,location:,command:C:\program Files <86>\DoTask\Driver\DokanUninstall.exe
The CA is configured as follows:
Created a CA based on "New EXE > Path referencing a directory".
Working Directory: <empty>
Filename & Command line: "[INSTALLDIR]\Driver\Uninstall.exe"
Return Processing: Synchronous (Check exit code)
In-Script Execution: Commit Execution in System Context
Install Exec Sequence: After RemoveFile
Install Exec Condition: Remove
everything else was left at the default
Do anyone have any ideas what to try next?
finally,I can fix my problem.I created CA Data.
The CA Data is configured as follows:
Install Exec Sequence: After UnpublishComponents
Install Exec Condition: Remove
Sounds like you have a race condition. If you are scheduling in commit execution that means you are running after RemoveFiles probably already removed the EXE. Also remember that if rollback is disabled that commit custom actions won't execute anyways.
I have been trying in the last days to understand how qmake works buy I'm stuck.
I want a project with the following structure:
root
bin
testjson
lib
libjson.so
src
testjson.cpp
All i wanted was to test the json library. I have created a new empty project in Qt Creator 2.3.0, and set up all the settings so the executable will run. Tested what I wanted and closed the application.
Later, when I opened Qt Creator again, I loaded the .pro file and surprise, when I try to run the project I get this message: "No executable specified." :| In this case I went to the project tab, and selected the executable manually but, as expected, when I tried to run it, I got this message "error while loading shared libraries: libjson.so: cannot open shared object file: No such file or directory". It was expected since the LD_LIBRARY_PATH is not set(it's like i'd run it from cli).
It looks like the .pro file isn't parsed properly because the 1st time, on the project tab when I was selectig Run tab, I'd see a message : "Parsing .pro file", and then the running config would get filled, and greyed out, so it means that the LD_LIBRARY_PATH was added by Qt Creator after parsing the .pro file.
Now my questing is: why was the .pro file parsed correctly 1st time?
Here's the .pro file:
!include(../../common.pri){
error(Couldn't find the common.pri file!)
}
TEMPLATE = app
SOURCES += testjson.cpp
CONFIG += console
TARGET = testjson
CONFIG(release, debug|release) {
DESTDIR = $$BinaryDir/Release
} else {
DESTDIR = $$BinaryDir/Debug
}
LIBS += -L$$LibraryDir -ljson
INCLUDEPATH += $$DefaultInclude
DEPENDPATH += $$LibraryDir
PS: The solution is to manually add the LD_LIBRARY_PATH to the building environment, but I find this not the right way to do it.
I think you have confusion between what is controlled by the qmake (.pro) file and what is controlled by your runtime environment. The .pro file is only specifies the BUILD environment, not the runtime environment. The .pro file is only used during the build process.
When you go to run the built code, whether from a command line or from within Qt Creator, you are dealing with the RUNTIME environment. If you tried running the program from the shell, you would have to specifically specify the LD_LIBRARY_PATH. From within Qt Creator, you will have to do the same thing.
[I only have Qt Creator 2.2 installed here, but it should be very similar in 2.3]
To set the runtime environment,
Select the Projects icon in the left tool bar.
On the top, select "Run Settings"
On the Run Settings page, go down to the "Run Environment" settings and click "Details" to show the details of the environment.
Click on "Add..." and add "LD_LIBRARY_PATH" with the appropriate settings.
When you are done, the setting will be stored with your project. [The settings are actually stored in a file with a ".user" ending, not the ".pro" file.]
When you go to run your project, the environment you setup under "Run Settings" will be used, and you application should start with the correct LD_LIBRARY_PATH.
If you don't want to manually add path to LD_LIBRARY_PATH in Qt, qmake has a variable for that, it's called QMAKE_LIBDIR. In my case I couldn't link the OpenCV libraries installed in a custom path (not in /usr) but this answer unblocked me. Basically this line tells Qt/qmake to look for libraries where you want it to:
QMAKE_LIBDIR = /path_to_your_libs