Is it possible to build a standalone Windows app using Visual Studio that runs Command-line commands and/or scripts ?
Yes, you can do this, and you can do it in multiple languages too.
For C#, according to this question, you can run:
string strCmdText;
strCmdText= "p4.exe jobs -e";
System.Diagnostics.Process.Start("CMD.exe",strCmdText);
In a nutshell, you can call the .NET API (see the Start documentation here ), and start an instance of CMD.exe (or bash or whatever else you want to call) and send it a command. You can get information on what the result of the script's run was using the properties and methods of the Process class.
Related
I have an app that listens to certain process events, such as starting a program and than recording the full commands. I would like to replay starting the programs using the commands as well. For some programs e.g. word, this works very well.
For windows app programs, this does not work. For example, starting calculator:
Command inputs: "C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_10.1709.2703.0_x64__8wekyb3d8bbwe\Calculator.exe"
Access is denied.
I could start the calculator using calc, but unfortunately, I don't have that information in my program. Is there any way to start such a program using the executable path?
I used admin mode for the latter command.
Have you tried running cmd as administrator?
Just kidding ;-)
Actually, starting Windows Store apps (or UWP apps, or whatever they are called these days) is not easy. Finding the correct command line for them is a very long-winded process. It's described here:
https://answers.microsoft.com/en-us/windows/forum/windows_10-windows_store/starting-windows-10-store-app-from-the-command/836354c5-b5af-4d6c-b414-80e40ed14675?auth=1
I know it's bad form to just give links as answers, but on this occasion the answer itself would take pages to write. If the above link disappears, google "Starting Windows Store apps from the command line".
I think cmd running as a normal user it required administrator access, try cms as administrator.
I've been learning shell script on my Mac recently. Take an application like Atlassian's SourceTree as an example. My understanding is that it's just a GUI for git commands, which can be executed through command line. Pressing a button just triggers a corresponding git command, which is effectively run through the command line behind the scenes. If that is the case, do all applications that have a GUI function this way? Are all applications essentially just running their commands through the machine's shell script? And if so, are the underlying commands that are being used publicly available, offering an API of sorts for any application?
This is more complex than that.
Many applications only have a GUI (e.g., Safari), many others only have a CLI (e.g., find).
When a GUI app and a CLI app perform the same function, they may communicate with each other or they may not:
As you point out a GUI application can run a CLI command behind the scene (with system() or popen() for instance)
An alternative is that both applications use the same underlying library
Or no code is shared at all (think of ls vs. Finder on Mac)
Finally on Mac some GUI apps can be controlled with Applescript language, which is available through osascript command. In other words, you can control iTunes with a bash script.
Definitely, not all applications behave that way. In fact, from my experience, I'd say that there are few applications that follow that. Most applications perform their own operations relying directly on the OS platform and functionalities, instead of executing shell commands which, in addition, are hard (and most of the time impossible) to port between OSs.
I need to create a GUI overlay that will provide status information to users while an install is taking place. The install happens through Powershell scripts. I would rather not rewrite the functionality that is already taking place in the scripts.
Are there any practical methods I can use to overlay a GUI over the scripts? I am thinking of something along the lines of an application installer that just calls the scripts and displays information about the status.
You can run PowerShell scripts from CSharp and interact with the PS runspace.
You can always wrap up these scripts in WinForms (PrimalForms Community Edition to design the UI) within PowerShell or use something like ShowUI (showui.codeplex.com).
Anything particularly wrong with using Write-Progress calls in your scripts?
I recently wrote an install cum config tool and this is what I did to run the PS scripts asynchronously from C#/Winforms - https://stackoverflow.com/a/10741061/763026 [Full code is there]
For example if App-A tries to installed App-B. Is there any way for App-A to know when App-B is finished installing and can be run?
update
to be specific I am trying to install ChromeSetup.exe on windows using AIR 2.
update 2
Good information guys, after reviewing all your answers is seems like I should run the installer with the -ms argument so it installs silently. Then listen for the NativeProcessExitEvent.Exit event. I will try that and see if it works.
It Depends (TM).
Most of the time, the installer for an app is a single executable - so you can launch it and wait until execution comes back to you, but I've seen some unholy messes like "downloader unpacker -> installer downloader -> installer unpacker -> installer" which launched the next executable in the background. Try it with the specific apps you're after and see if the simple system() method works. If not, you'd have to monitor the process list to see if the other installer is done yet.
Installers generally generate logs that give output for events during install. It may be possible in your case to search for a generated log file from App-B installer and look at it to gauge success or failure. But if you're just running the App-B installer as a command line executable you could just invoke it synchronously and wait on it to complete.
Typically the installer would just exit and the system() call would return.
Or you can script installers and their own scripting language would control the sequence.
Generally speaking, the installer will run as a process, and you can wait for that process to finish. Under POSIX you can use spawn, and quite a few other systems provide the same or least something quite similar.
If I understand well, you are writing an installer and you want to install Chrome as a pre-requisite or something like that?
If so, you can run the installer silently with the "-ms" parameter according to what I could see on the Web.
Then how to call it depends on which programming language or system you're writing the installer on: for example, from a batch file, you would do
start /wait "" GoogleSetup.exe -ms
but how to call a separate process and wait for its termination depends on the development language and system you're using. Most of them offer functions to launch external processes and wait for their termination almost effortlessly.
I'm trying to build our web application automatically. I need to be able to copy the VB6 DLL's to a server and register them since the webapp is using them as a backend. I can't seem to find a way to register them from another machine. I can't use rsh because it isn't allowed on this server.
You could create a ASP.NET form in a separate ASP application, that accepts DLL paths to register and schedules a batch file (with job ID, timestamp and sequence number in filename to uniquify) to run with Windows Scheduler at the start of the next minute, outputting register result to a result text file. And which deletes older time stamp batch and result files. And which supports status code/text output enquiry/return for previous jobs. And call this ASP interface from the command line over the network using a C# script. Yuck. Really really horrible rickety rickety solution and might be more work than the application (itself).
Borland C++ used to include a remote commands tool I believe, a decade ago. And there's plenty of tools for remoting.
But without suitable arbitrary remote commands or shells permission, looking for remote registration, you're options are limited.