I have created setup using installshield and everything is work file. Now I have one batch file and want to run with setup. I know we can create custom action and I have already created custom action for run powershell script and it is working fine.
Can anyone help/guide me for using which custom action I can execute the batch file?
Also I want to run MySQL script from installshield setup.
What I have tried:
I have tried to create different custom action but I don't know exactly which custom action is used for execute the batch file.
ASSUMING AN MSI INSTALLATION:
In your MSI Installation Designer pane, click on "Custom Actions and Sequences"; in the top part of the middle pane right click on "Custom Actions" and choose "New EXE -> Stored in Binary Table". Give it a name (and description, if you like). When it saves, right-click it and start the Custom Action Wizard.
The Action Type should be "Launch an executable" and the Location should be "Stored in the Directory Table".
For Action Parameters "Source", choose the directory you want to start in. For target enter a command to invoke your script, like cmd /c .\RunMyScript.bat arg1 arg2 ... (assuming the script is in the directory you started in.) If the script is in a different folder you can put one of your directory variables in brackets: cmd /c [INSTALLDIR]bin\script.bat. Typically the directory variable will already include a trailing backslash; using these variables with the bracket syntax helps make sure the action works even if the user chooses a different installation folder.
If the script is in a folder that is not a required part of the installation, you may need to make your command be something like cmd /c if exist .\script.bat .\script.bat - so that the custom action does not fail if the feature containing your script is not selected for install (or is removed when an installation is modified.)
I have typically wanted execution to be synchronous (install waits until script finishes before moving on); if your script does not return a reliable exit code, or if you don't want the installation to abort if the script fails, choose the one with "(Ignores error code)".
The custom action should typically be in the InstallExec sequence, after files are installed (but a script you run during an uninstall or repair could run earlier or in a different sequence.)
Related
I'm using Windows 10 and installed gitlab-runner using the Gitlab's doc.
After a successful installation and registration, I try to leave the folderI used to install (C:\Gitlab-Runner in my instance) and try to run gitlab-runner. I get the response: 'gitlab-runner' is not recognized as an internal or external command, operable program or batch file.
I am able to run without issue in the C:\Gitlab-Runner folder, but nowhere else.
Based on the documentation and tutorials I looked at, I wouldn't expect this behavior; am I supposed to?
Did you check to ensure that it was added to The windows environment. You will likely need to update the path variable to include the path that you are using to run the command.
On windows, you add to the PATH variable with the following steps (yanked from google search page):
On the Windows taskbar, right-click the Windows icon and select System.
In the Settings window, under Related Settings, click Advanced system settings. ...
On the Advanced tab, click Environment Variables. ...
Click New to create a new environment variable.
Once you've added C:/Gitlab-runner/ to PATH, I believe you should be able to invoke with gitlab-runner.
The only thing I'll add is that, for setting PATH, the last step above is most likely unnecessary, as there will already be a variable named PATH with a list of directories stored in it. Just click EDIT and add your directory to the end of the list. Be sure to add the separator that is used for the others (I believe it's a semicolon on Windows...)
Solved. I need to call C:/Gitlab-runner/gitlab-runner rather than just gitlab-runner in other directories.
Please make sure the name of the exe is correct in the folder C:\GitLab-Runner
In my situation, I have the gilab-runner.exe.exe, there was an extra .exe in the file name though its not showing in the directory.
enter image description here
I am building an installer for our product which works well. I've managed to build custom actions to install our services including a MySQL server.
The problem I have is executing a sql file to build the schema structures.
I have a custom action which uses mysql.exe and the command line arguments:
--port=### --user=### --password=### < "[INSTALLDIR]db\EmptyStruct.sql"
It tries to execute this ok but the cmd window which pops up, during the install, just runs through the mysql.exe command line options, which says to me that the command line it gets passed is not correct. However if I run the command manually after the install, it works perfectly.
Does anyone has any ideas please.
I'm making a few assumptions here:
You have a Windows Installer exe custom action that specifies mysql.exe and a command line as you showed
You are expecting the contents of [INSTALLDIR]db\EmptyStruct.sql to be redirected to mysql.exe's standard input
This will not happen. Behind the scenes, Windows Installer's exe custom action support uses the CreateProcess API and this API will interpret command lines literally. However the redirect < needs special handling to actually perform redirection.
To get that behavior, you must use a layer of indirection. For example, you could run cmd.exe as the exe, and give it a command line that will make it interpret and run the command line mysql.exe --port= ... < "[INSTALLDIR]...". However, if you didn't already have a command prompt showing, this would cause one to show up. If you want to avoid that, you could write a custom wrapper that performs the redirection for you, either as a C++ DLL or, say, InstallScript action.
Alternately, if there is a parameter that tells mysql.exe to run a script from a file, you could pass that instead of using redirection. I wasn't able to find evidence of such a parameter in a quick web search.
Thanks for your comments Michael and I used cmd.exe /k AddStruct.bat to accomplish the task!
I have set up Jenkins so that it builds my project, runs some tests and then creates an HTML page containing a report.
I made a .bat file to open the html report in my browser. There is just one line in that .bat file :
"E:\user\Visual Studio 2010\JenkinsWorkspace\JobTest\index.html"
When I run that .bat in a prompt myself, the page index.html is open (so it works).
But the problem is that when I set up a Jenkins' job to run that .bat, nothing happens.
The job gets stuck after calling the .bat and never finishes.
Any idea why?
Note: I have other .bat (that do not open html pages) that are successfully executed by Jenkins.
EDIT: here is the errors I get in the prompt log from Jenkins's menu :
C:\Program Files\Jenkins\jobs\JobTest2_enUnSeulScript\workspace>echo "
Opening html page" " >> Opening html page"
C:\Program
Files\Jenkins\jobs\JobTest2_enUnSeulScript\workspace>"C:\Program
Files\Google\Chrome\Application\chrome.exe" "E:\user\Visual
Studio 2010\JenkinsWorkspace\JobTest\testResults.14h05m15s65ms.11.04.2013.trx.htm"
[688:3900:0411/140520:ERROR:gpu_info_collector_win.cc(96)] Can't
retrieve a valid WinSAT assessment.
[688:3900:0411/140520:ERROR:process_singleton_win.cc(540)] Lock file
can not be created! Error code: 32
[688:3900:0411/140520:ERROR:chrome_browser_main.cc(1157)] Failed to
create a ProcessSingleton for your profile directory. This means that
running multiple instances would start multiple browser processes
rather than opening a new window in the existing process. Aborting now
to avoid profile corruption.
Build step 'Exécuter une ligne de commande batch Windows' marked build as failure [htmlpublisher]
Archiving HTML reports... [htmlpublisher] Archiving at PROJECT level
E:\user\Visual Studio 2010\JenkinsWorkspace\JobTest to C:\Program
Files\Jenkins\jobs\JobTest2_enUnSeulScript\htmlreports\HTML_Tests_Report
Finished: FAILURE
If you are running Jenkins as a Window's service, you will probably need to enable the service to interact with the desktop. Do the following:
Open the Services module
Right-click on Jenkins and select "Properties"
On the "Log On" tab, run as "Local System account" and select the "Allow service to interact with desktop" checkbox
-- OR --
You can run Jenkins via the command-line. Ie: "java -jar jenkins.war".
I am guessing that your Jenkins install is running as a Windows Service. When Jenkins is run as a service on a Windows machine it runs under the System account, not a user account. The System account usually does not have the same settings as a user account.
You might want to try starting a CMD shell as the System Account. (The answers to this question should help you with that: How Do You Run CMD under System Account.) From there, try running the batch file and see what happens. You may find that you need to setup somethings like the PATH before it works.
I know this is late, but I just answered another question on how to open an .exe (or .bat) from Jenkins's service on Windows
Open Excel on Jenkins CI
The issue is that while your command actually works, it does that in Session 0 (which is the session of Local System user that launched your Jenkins service), which you cannot see while being logged in through your own user account, most likely in Session 1.
Hope this helps
I'm working on a simple TCL script that makes a few Tk dialogs appear and then compresses a file given by argv. It works just fine from the terminal by running "./script file", but since it's a graphical wrapper for a command-line utility, I want it to run from the right-click menu in a file manager.
I copied it to /usr/bin and used Caja's "Open With Other Application..." option on a random file (no spaces in the path), and entered the name of my script as the application to use. When I tried to open the file this way, there were no dialogs and no archive.
However when I tried to run the script from the terminal again, without the "./", it still worked.
What needs to be done to run a TCL script on a file from the right-click menu and still be platform independant?
Maybe you could start with determining wether Tcl or the file manager is the problem. Write a shell script...
#!/bin/sh
exec rm -- "$#"
...make it executable with chmod +x and try to use it as an "other application" on a file you don't care about. If the file isn't erased, Tcl isn't to blaim.
I have fixed the script in question. I don't know why the dialogs broke or why they are working now, but the archive was apparently failing to appear because the script's working directory was automatically set to my home folder by the file manager.
The code below is what I used to direct my script to the right folder. It changes the working directory to the one containing the file that the script is being run on.
cd [file dirname $argv]
Once I set that, most of my issues seemed to be resolved, and I can now continue dveloping my script.
I have a .dtsx file (an SSIS package) that downloads files from an FTP server and imports data. It runs fine whenever I run it manually. However, when I schedule calling the package as a step in a SQL server agent job, it fails. The step it fails at is the one where I call a .bat file. The error in the job history viewer says this:
Error: 2009-05-26 12:52:25.64
Code: 0xC0029151 Source: Execute
batch file Execute Process Task
Description: In Executing
"D:\xxx\import.bat" "" at "", The
process exit code was "1" while the
expected was "0". End Error DTExec:
The package execution returned
DTSER_FAILURE (1).
I think it's a permissions issue, but I'm not sure how to resolve this. The job owner is an admin user, so I've verified they have permissions to the directory where the .bat file is located. I've tried going into Services and changing the "Log On As" option for SQL Server Agent, and neither option works (Local System Account and This Account). Does anyone have ideas as to what other permissions need to be adjusted in order to get this to work?
I tried executing just the batch file as a SQL Job step, and it gave more specifics. It showed that it failed when I was trying to call an executable, which was in the same directory as my .bat file, but not in the windows/system32 directory, which is where it was executing from.
I moved the executable to the system32 directory, but then I had no clue where my files were being downloaded to. Then I found that there's a property for the Execute Process Task (the one that executes the .bat) called WorkingDirectory. I set this to be the directory where the bat is located, moved the executable back into the same one as the .bat file, and it's now working as expected.
For me it was a permissions issue. Go to Environment --> Directories, then change Local directory to something the SQLAgentUser can access. I used C:\temp. Click the dropdown for Save, and choose "Set defaults".
Are you executing the SSIS job in the batch file, or is the batch file a step in the SSIS control flow?
I'm assuming the latter for this answer. What task are you using to execute the batch file (e.g. simple execute program task or a script task). If the latter, it looks like your batch file is actually failing on some step, not the SSIS script. I'd check the permissions of what your batch file is trying to access
In fact, it might be a better idea to rewrite the batch file as a script task in SSIS, because you'll get much better error reporting (it'll tell you which step in the script fails).
You could try executing the batch file using the runas command in a command window. If you try and execute it under the local system or network system account, it should give you a better error. If it does error, you can check the error level by going "echo %ERRORLEVEL%".
If it wasn't the latter, and you're executing the SSIS package via a batch file, why?
Are you possibly accessing a mapped drive in your .bat file? If so, you can't rely on the mapped drive from within the service, so you'd have to use UNC path.
I had the same error and I resolved it by logging on to the user account that runs the job, opened Coreftp site in question there, test the site access, made the change there (in my case, I had to reenter the new password) and now it works.
So yes, it is an issue of file access. This one is file access to the coreftp site in question.