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]
Related
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.
I need execute simply command in cmd.exe, for example:
ls -l
I care to read the result of executing this command, but I know I didn't Process library. Could you help me?
You can use so called "brokered components" to achieve this. This worked for Windows 8.1, I'm not 100% sure but think it still works for W10.
It's a little hacky. The reason is that it requires extra steps to get along with the security restrictions in Windows and therefore you need some additional projects and stuff
Here's a link to a blogpost on this:https://blogs.msdn.microsoft.com/mim/2014/06/24/create-a-winrt-brokered-component-feedback-from-a-real-life-developement/ You will find more details if you search for "brokered components".
You can see it in action in a video I recorded for YouTube some month ago: https://www.youtube.com/watch?v=3yiZBG6PQmY
I am trying to do my first script. To simply get PowerShell to pull up a script typed up in notepad and saved as a .ps1 file titled "test" (have also tried Script, but know names have nothing to do with it):
Write-Host "Hello, World!"
In PowerShell I am typing
& "C:\Scripts\test.ps1"
As well as
./test.ps1
And am only met with this:
./test.ps1.txt : The term './test.ps1.txt' is not recognized as the name of a
cmdlet, function, script file, or operable program. Check the spelling of the
name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ ./test.ps1.txt
+ ~~~~~~~~~~~~~~
+ CategoryInfo: ObjectNotFound: (./test.ps1.txt:String) [], CommandNotFoundException
Have tried renaming the file within PowerShell with
PS C:\Scripts> Rename-Item test.ps1.txt test.ps1
I have switched between RemoteSigned and Unrestricted, I have tried a code including executionpolicy bypass (I do apologize, I closed my window without writing that one down). As far as I know everything is up to date and I am running Windows 10, Windows PowerShell, and regular Windows Notepad.
First, I'd HIGHLY recommend using the Windows PowerShell ISE for writing scripts. It's free, and provides a pretty decent console/editor experience, given that it's free (there are allegedly better ones out there, but this has always done just fine for me). I use Visual Studio for other stuff, and while it is an EXPONENTIALLY better product (and should be), the PowerShell ISE is pretty feature-rich.
Next, if you're just getting started, you should check out Don Jone's "Learn PowerShell 3.0 in a Month of Lunches" book. It's two versions behind the most current, however, all of the information is still relevant, and once you've finished the book, you'll be able to seek help for anything else pretty easily on your own. It covers all the basics, and is a very good first step to learning the language.
Now, to answer your question: PowerShell scripts commonly have the .ps1 file extension. Other extensions are generally used for modules (.psm1) or other helper content that Windows PowerShell leverages. For most things, you'll stick to .ps1, and when you've reached a point where you start needing the other extensions, I suspect you will have no problems identifying which ones you need.
There are two ways generally call a PowerShell script. The first is from a normal command prompt, and telling PowerShell to execute your script. This is shown below:
powershell.exe -File MyScript.ps1
There are some additional parameters that I'd recommend you use, but usage is dependent on your requirements. Here's what I usually tag on mine:
powershell.exe -NoProfile -ExecutionPolicy RemoteSigned -File MyScript.ps1
This will tell the PowerShell process to ignore any PowerShell profiles you have set up, which is ideal if you have a bunch of stuff in your profile script that does things like read console input (for your current situation, I'm going to assume you don't, but you may in the future). The other is that ExecutionPolicy one: RemoteSigned will tell PowerShell to basically ignore anything that's been downloaded from the interwebs, but allow anything originating inside your network to run free. Probably not the best practice, but this isn't a TERRIBLE policy if you can trust that your script repository is secured. If not, then go for something tighter than this (you can read up on execution policies by typing "Get-Help about_Execution_Policies" in the PowerShell prompt, or by visiting the TechNet page about them -- the content should be similar if not identical).
The second way is from inside of a Windows PowerShell script. It's actually much easier to do. Note that you must set your execution policy to something that will allow scripts to run, but thereafter, you're smooth sailing.
. .\MyScript.ps1
This is called "dot-sourcing" your script. The advantage of doing this from within Windows PowerShell is that if you've got something like a script full of functions, they get added to the current scope (Get-Help about_Scopes), which means they're now available in your current session. A good example would be defining a function called "Test-DomainConnection" in a script you distribute with your main script: You'd dot-source the script that is distributed with the main one (this is done usually when you separate your "standard" PowerShell functions from your main script), and then use the functions in the main script. There are pros and cons to this approach, but it seems to be generally recommended (there may be some community extensions out there that remove the need to manage this manually).
For additional information, you can call Get-Help about_Scripts from inside Windows PowerShell. Because you're using Windows 10, you may need to run Update-Help from an administrative PowerShell window before the help content is available on your local system.
If you have any more questions, feel free to message me :) I've been doing PowerShell for a while and may be able to help out.
Powershell processes in order (top-down) so the function definition needs to be before the function call:
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.
Looking for a better Windows XP command-line interface. The Visual Studio Command Prompt isn't near as nice as the Linux/OSX terminals.
Thoughts?
edit:
Answers: Console on Sourceforge, and the Windows Powershell. Thanks, I'll go dig them up and evaluate them.
The Cygwin package is too much overhead for what I want.
edit2:
Looks like the Windows Powershell for now. Its copy&paste functionality isn't great, but MS supports it.
Take a look at Console2 http://sourceforge.net/projects/console/
It's features:
"multiple tabs, text editor-like text selection, different background types, alpha and color-key transparency, configurable font, different window styles"
As has your question been tagged, have you tried Windows PowerShell? It's paradigm is based on unix's pipes but instead of outputting text the processes output .Net objects.
cygwin? www.cygwin.com. Or mingwin?
Cygwin
This is an answer extending line.
I'm not clear on what you mean by Linux/OSX command prompts being "nice". If you just mean that they provide more utilities, I usually install Windows Services for Unix to add common programs like grep and vi.
I see you put "powershell" as one of your tags. Maybe you could help direct our answers by explaining what you don't like about PowerShell as a replacement for cmd.exe?
I use Take Command from JP Software
Cygwin is a good alternative. You can run Bash or other shells on Windows. You get most of your classic Linux/UNIX commands, shell scripting, etc. You even get the GNU compilers and can avoid Visual Studio if you wish. From Cygwin, you can access your regular Windows programs, drives, etc so there's rarely a reason to go back to cmd.exe.
If you are just looking to automate tasks via shell scripts (not interactive shell), then you should look at Windows Scripting Host. WSH is a feature-rich scripting environment for Windows that comes pre-installed on all modern versions of Windows.
I've been combining putty, cygwin, screen, and zsh(not bash) lately. I like a lot of the features of zsh, like autocd which and auto-pushd, which put the directories you change into onto the directory stack without having to type pushd. I also like that fact that multiple shells share history, and don't overwrite each other. Screen lets me run multiple zsh shells in one putty window. You can get zsh and screen from the cygwin site. I run: putty -cygterm screen
You'll also need the patched version of putty that has the -cygterm support.
GitBash by git is also a good option. It can be configured to be used in unix like environment.
It can be downloaded from here http://msysgit.github.io/