Can PowerShell be automated? I.e. is there a COM interface to PowerShell that can be imported into Delphi as a type-library interface to automate it, and if so, what is the relevant file name(s)?
Googling, etc, I've found numerous references to automating things from within a PowerShell script, but I haven't been able to find anything to say whether or not I could control PowerShell itself via COM as I could it it were MS Word or whatever, and maybe receive events from it. What I'm wanting to do is to hand it a command from within a Delphi app to execute some arbitrary CmdLet and get status information back from it while it's executing the script (otherwise I'd make do with doing a ShellExecute on it).
I'm not sure whether the fact that I have been able to find anything is because PowerShell is by design not automatable or because I haven't managed to frame an effective query that filters out all the automation that can be done using PowerShell as a script host.
This is using XE8 on Win7 64-bit or its Win10 upgrade, btw.
Elaborating on RaelB's suggestion of http://delphidabbler.com/software/consoleapp:
This worked for me since Powershell itself can be run as a console app. If you wanted to run CmdLet "abc -param", then you would call the Execute method of a TPJConsoleApp instance:
app.Execute ('powershell -command abc -param')
Peter Johnson (delphiDabbler) provides several examples for interacting with the console app via pipes, files, etc. to get your status information back from the Cmdlet's stdOut (stdIn and stdErr are also available). Working code can be quickly derived from the most appropriate example.
Optionally you may want to provide additional parameters for powershell:
https://msdn.microsoft.com/en-us/powershell/scripting/core-powershell/console/powershell.exe-command-line-help
Related
My setup.exe installs several files including an executable.
When I ask this executable to launch a help file with "ShellExecute ... pdf", it happens nothing visible, but in the task manager, I can see that Acrobat Reader has been launched.
But it is stuck and can no more be launched, even manually until I have removed the frozen process.
What is the solution?
Almost certainly the issue is as discussed in the comments. Namely that the installer program runs as elevated administrator, and modern Acrobat Reader won't open documents when the process is executed as elevated administrator.
You can check this yourself quite easily with a simple program that contains a single call to ShellExecute to open the document in question. Run the program as standard user and see what happens with the call to ShellExecute. Then run the program as administrator and check that the document fails to open.
The solution is for you to run the program as standard user. That's not an easy thing to arrange from an elevated process. It involves quite a lot of furkling around. This MSDN article is the best source of information that I know of on the topic: How do I start a program as the desktop user from an elevated app? The code supplied is in C++ but since it is almost entirely Win32 API calls it should be a trivial conversion task.
I'am using the WAMPServer, and it's located in d:/wamp/. Is there a way to show logging window or console in realtime as I'am crawling on my server web ?
On unix/linux boxes I tend to use the tail command to watch logs as I browse for debugging. Of course, Windows has no equivalent, but there are a few options. The one I settled with was mTAIL. It's a standalone app and not a command line program, but it does exactly what you'd expect:
I was going to suggest using unxtools, a suite of ported GNU tools that can be used on the command line, but it's out of date and trying it on more recent versions of Windows I had problems. You can download them from sourceforge if you want to take a look. Also tail for Windows, is another Windows app that unfortunately doesn't seem to work on later versions, but included here in case it saves anyone the time looking.
Of course, you may find that if you prefer the command line you want to look at getting cygwin installed, which contains a host of commands you could use for the task you have.
I have an application which needs to run with different user name.
I am trying to call "runas.exe" to call the batch file which calls my application.
When I tried this in command prompt it worked fine. One drawback is I have to provide password
I am wondering if this is possible as this runs on build sever without anyone intervention
Here http://blogs.msdn.com/b/oldnewthing/archive/2004/11/29/271551.aspx Microsoft explains why we cannot give password as command line parameter
I don't know what could be the better approach. Can anyone suggest any good alternative
I use Windows 2008 R2 64 bit
You can't do this, unless you write a small program which does this for you. Batch won't cut it for obvious security reasons.
A sample program that will work in windows xp can be found here.
I have a pre build event set up to generate the version/build number to embed in my exe. The event consists of a call to a batch file that does the actual work (a parameter is passed to the batch file). The batch file works as it should on all of the computers I've tried it on, including the Windows XP computers. It also runs fine as a pre build event on the 3 computers here running windows 7. The pre build event fails, however, on Windows XP. Delphi returns an error code that I can't seem to find a reference to anywhere, "20018".
I've tried a number variations to the way I call the batch file without any luck. Does anyone have an idea what's happening?
The build event is as follows:
call "..\..\Build Tools\PreBuild.bat" "$(PROJECTDIR)"
UPDATE:
I've removed the source of the batch file, since it had no relevance for the actual problem.
You gave so little information that I am tempted to vote to close. Instead I will venture a wild guess. You should post the commands in your post-build step.
If you don't know which line is failing, try the first one alone, and remove the rest, and see if that passes.
For example, I often have problems on XP machines using XCOPY commands in post-build steps, and these commands often result in really odd error codes that I am unable to diagnose or determine the meaning of. So if you have an XCOPY command, you should try the XCOPY inside and outside the build environment, and see if it works on that Windows XP box, for example.
You can copy the commands, as they are run, in their macros-expanded form, from the "Output" tab in the Rad Studio IDE, paste them into notepad, run them as a batch file, and try to figure out why they don't work on windows XP.
Here's an example of a workaround, using XCOPY. If this fails on XP, I tweak it till it works:
XCOPY SourceDir DestDir
I have had to fix it this way:
XCOPY.exe SourceDir DestDir
In another case, I found that I had to fix it this way:
call XCOPY SourceDir DestDir
You ALSO mention you are simply running a mysterious batch file and you fail to mention what it does. So let's see, what we could do differently to run a batch file from a post build step.... When I run a batch file like this, I sometimes have problems on XP, like this:
batchfilename.cmd
But when I run it differently, I find it worked on XP, but I lose the command line output:
call batchfilename.cmd
It seemed that something strange was happening when running post-build steps in the IDE, that could be resolved by trying the commands outside the IDE, in various forms.
The number (20018) you mention is a bit of a silly thing to go googling, it's probably the ERRORLEVEL (return value to the command shell) of whatever tool you are running in your batch file. Since you told us nothing about what tools you're running, I wonder if you have even done the basic step of looking at what happens when you run that batch file OUTSIDE the IDE on that XP machine. My guess is that if it didn't come from your own batch file, that it came from deep in the guts of MSBUILD itself, which is something that very few Delphi people will know the source code to (even the Delphi team itself is using a binary from Microsoft to provide MSBUild functionality). I notice that MSBUILD's built in tasks for doing post-build and pre-build steps are an area of the IDE that need improvement, especially when it comes to debugging problems like this. You can however, simply run them outside the IDE and see if they work that way, and you can try stuff, as I have suggested above.
If this is your batch file ... I suggest that due to dependency issues, you might not want to use such a batch file technique to modify an RC file, as it might expose some strange dependency issues in MSBUILD with RAD/Delphi build tasks. I have also seen some weird BRCC32 failures, on XP that I have not been able to reproduce.
Ok, I finally found the answer here:
http://delphi.about.com/od/devutilities/a/pre_post_build.htm
The problem was spaces in the path to the batch file being called. Apparently this isn't a problem in Windows 7.
Removing the space in the build tools directory and changing the pre build event to the following fixed the problem:
call ..\..\BuildTools\PreBuild.bat "$(PROJECTDIR)"
Here's the important bit from the link:
Command Line: This is the trickiest of them all, but after you get one working, they’re all easy. The trick here is not to use quotes on the program’s name but instead use the windows SFN (Short File Name). The reason is that, should you need to use quotes to enclose the path of your file, the IDE gets confused with too many quotes. So, these are the wrong ways of adding that command line above:
C:\Program Files\SoftwarePassport\Armadillo.exe D:\Dev\My Prog\Prot.arm /P
"C:\Program Files\SoftwarePassport\Armadillo.exe" D:\Dev\My Prog\Prot.arm /P
C:\Program Files\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
"C:\Program Files\SoftwarePassport\Armadillo.exe" "D:\Dev\My Prog\Prot.arm" /P
This last one should work, if it were not for the IDE to be confused with it. So, what does work is either of these:
C:\Progra~1\Softwa~1\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
C:\Progra~1\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
My problem is to create an ant target for automating our installer running in console mode.
The installer is created using InstallAnywhere 2008, which UniversalExtractor recognizes as a 7-zip archive. Once I have the archive unpacked, it appears that the task can use an input file to drive the console (at the very least, it appears that emitting a quit shuts everything down correctly, and output is captured).
So it looks to me as though I have all of the pieces I need for proving out this idea except a clean way to perform-self-extraction-then-stop. Searching for a command-line argument to stop the auto execution has not produced a likely candidate, and the only suitable ant task I've found ( http://www.pharmasoft.be/7z/ ) isn't so clearly documented that I have a lot of confidence in it.
The completed completed is expected to work in Windows, Linux, and a small handful of other Unix environments.
What's the best practice to use here?
Since you control the installer creation, can you run the self-extraction step on your machine, package the results before the installer is launched in a ZIP file, etc. and use that instead of the single file executable? Not very elegant but it may work.
Also, I am a bit hesitant to blatantly promote my project :) but since it has been a while since you asked the question and nobody has answered, have you considered an alternative? Our project InstallBuilder allows you to install in unattended mode directly, without having to autoextract the contents. Just invoke the executable with --mode unattended, pass any additional options you may need from the command line or an external file and you are good to go. We have a lot of ex-InstallAnywhere customers :)