I have searched to find way to automate GUI using powershell and come across with some good online sources. But they are all using custom cmdlet. As new version of powershell is in progress, Is there any new cmdlet are availed for GUI automation?
Don't think there will be anything specifically for UI automation.
I made a blog post with all of the new commands in the Windows 8 developer preview. Nothing for UI automation. You can download the current version CTP 2 here and check it out.
You'll probably still have to rely on third party stuff. Like WASP.
UI automation is very much subjective to the framework and other aspects of UI development. So, I don't expect PowerShell core to support anything like that. There are, however, community extensions to do a limited set of UI automation. As Andy points out, WASP is one of them. There are a few articles on MSDN around UI automation using PowerShell such as this: http://msdn.microsoft.com/en-us/magazine/cc163301.aspx.
Related
I'm trying to create an appointment only using PowerShell. Is anyone here who knows how to do that?
I've already tried to use EWS, but I'm not sure how to do that right.
Thank you for every answer!
It is not clear where you run the PowerShell script...
You may consider automating Outlook for creating an appointment item. Read more about that in the Outlook Email Automation with PowerShell article.
However, Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
My team and I are designing a diagnostic test tool as part of our next product. The test tool will exercise a request/response API and display asynchronous events. As part of the diagnostic tool suite, we will also be providing cmdlets for the entire product API.
Is it worth embedding PowerShell execution into the tool UI ? What are other development teams doing ?
The scripts can still run stand alone in any PowerShell window or tool. From a user's perspective, they would gain the ability to launch scripts from our UI. And, since the UI can be monitoring the same devices that the scripts act on, it brings some unity to the execution of a script and monitoring of the results. Embedding script execution brings more work to the project and I'm not sure how we want to handle displaying the results of the scripts.
Do most PowerShell users expect to run their scripts from their own shell environments or within tools that come from their product vendors ? Note, our diagnostic tool will not be automatically generating scripts for the users as some Microsoft tools do (it might be valuable for inexperienced PowerShell users, but we are expecting most scripts to be fairly simple, like executing a command on a series of devices).
Fortunately embedding the PowerShell engine and execute commands/scripts and getting the results back is pretty trivial. That said, I'm not sure you scenario is one where I would embed PowerShell. You ask if folks prefer to run scripts from their own shells or from within the Tool Vendors environment. I can't speak for everybody but the shells and editors that I use support some nifty features for debugging, code folding, syntax highlighting, multiple runspaces, etc. I'm not sure you would want to go through the effort to provide similar capabilities.
One reason to embed PowerShell is to execute the same PowerShell cmdlets as part of your core diagnostics and monitoring engine. That way you don't have to duplicate functionality between your diagnostic tool app engine and the cmdlets that your customers use for automation. It sounds like the code you use to do the diagnostics and monitoring in the app is different than the code in the cmdlets? Or is there common code shared between the app and the cmdlets?
Another reason to embed PowerShell is to allow the app itself to be scriptable but this doesn't appear to fit your scenario.
Another reason to embed PowerShell is if you are implementing a new host - ie you provide some unique editing or shell functionality. Some apps that do this are PowerGUI (which allows you to launch scripts IIRC) and PowerShell Plus.
Yet another reason I have embedded PowerShell in an application is because I knew I could get certain results in much less code than the equivalent C# code. This is a weaker reason and I probably wouldn't do this in a commercial app but I have used this for one-off programs.
I agree with both Jaykul and Keith Hill - the answer is yes.
There are several approaches you could use. But in general, I'd recommend you a) create key cmdlets as part of the UI for your app and b) you build the GUI on top of PowerShell (in the same way the Exchange team has done.
Doing this follows Microsoft's lead (all applications have to have a PowerShell interface) that is also being taken up by others (e.g. VMware, and even Symantec leverage PowerShell in their applications.
Creating cmdlets (and possibly a provider) is pretty straightforward - there's a great cmdlet designer recently released (see http://blogs.msdn.com/powershell/archive/2009/10/16/announcing-open-source-powershell-cmdlet-and-help-designer.aspx) for this tool.
Hope this helps!
Yeah, the main reason I'd consider actually embedding PowerShell in that scenario is if your UI could generate PowerShell scripts for the actions the users take in the UI, so they could see what was happening, and easily learn how to automate it. That would require designing the UI based on PowerShell from the beginning ... so it sounds to me like you're better off just providing the cmdlets and samples ;)
Microsoft seems to be heavily pushing that their server applications (i.e SQL Server 2008, Exchange Server, etc) all have some type of PowerShell integration. The logic makes sense in that one can choose to manage the application from a GUI or CLI.
Therefore if one were to follow that trend and want to build an application that had a PowerShell interface, how would one even start?
Has anyone in the community done this type of thing? If so, what seems to be the best approach?
Update:
The UI needs to have a certain look/feel. Therefore, PowerGUI does not lend itself in this situation. However, I've used PowerGUI and do agree that it can help bridge gaps.
Part of the confusion is really whether or not hosting PowerShell is necessary in order to build an application on top of it. From what I've found, it is not (i.e. Cmdlet's). However, I have not seen anyone really discuss this in the answers yet.
Start here: Writing a Windows PowerShell Host Application
Exchange 2007 admin console hosts PS directly, and surfaces every UI action by showing a ubiquitous "and here's the PowerShell you just asked me to do" UI model). SQL Server 2005 & 8 admin consoles demo the concept of surfacing everything in a UI as scripts as a way of dogfooding scripting abilities (but there is little PowerShell support in SQL Server) (Distinction between Exchange and SQL Server's type of support added in response Shaw's comment, thanks)
PowerScripting podcast has a few interviews on topics like this. Also get-scripting podcast
I attended a PowerShell / MMC 3.0 Devlab at Microsoft a few years ago that taught how to do this very thing. The basic idea was to create the "management functionality" via a series of PowerShell cmdlets in a PSSnapin for your application. CLI oriented folks can just load the snapin and party on your cmdlets directly. For the GUI oriented, you build a MMC snapin that hosts a PowerShell runspace which, in response to GUI actions, executes the appropriate PowerShell cmdlets to tweak the application that is being managed. For bonus points, you display what PowerShell code will be executed by the MMC GUI such that the code can be copied and pasted into a script. There are plenty of examples out on the web that show how to host a PowerShell runspace in your (or the MMC) process and execute PowerShell script in that runspace and get back results.
This is an intriguing idea!
I haven't ever thought about it, and I have no idea if I think it's a good idea, but some creative things could be done.
For example, suppose you have some typical administrative-ish piece of software. Don't really care what, specifically. In a classic app dev't scenario, I'd typically try to generate a list of Command objects (things that'd implement some sort of ICommand), and then my UI would bind to those.
Suppose, now, that you were to instead create a cmdlet for each Command. The UI would more-or-less exist as a friendly interface for the core logic in the suite of cmdlets.
Yeah, ok, nothing new here. People've been doing this for a long time, building up GUIs around command-line tools. I think the key difference is that you'd instead be building up individual command line tools from the concept of the application itself. Heck, it might make more sense for both the application and the cmdlets to reference some shared library of commands instead of making the GUI sit on top of the cmdlets themselves.
Errr- sorry for the scatterbrained response. This answer was pretty much purely stream-of-consciousness. :)
You could try primal forms for building a complete application from a script or you need to build your application with an snappin cmdlets (the previous being what is used by sql, exchange etc.) but link to primail forms here
http://www.primaltools.com/products/info.asp?p=PrimalForms
We are discussing development of an improved management infrastructure for our distributed system.
We use COM, web services and .NET components. Since we're based on Microsoft Windows Server XP/2003, I guess, we basically have two options:
Powershell cmdlets
WMI classes using System.Management and WMI providers for native code (class, instance, method, event)
Why would we choose Powershell over WMI?
I would choose PowerShell over WMI for the following reasons:
Writing a cmdlet is only adding a .NET Class.
The PowerShell runtime provides command line parsing built in.
Writing your management interface in PowerShell allows administrators the ability to integrate management of your application with that of other applications and services (like Exchange, Active Directory, or SQL Server).
The PowerShell environment makes the pipeline available to administrators, enabling management tasks for your application to be done more efficiently.
Discoverability. PowerShell, via Get-Command, Get-Member, and Get-Help, provides an extremely discoverable environment for admins to work in, resulting in a shorter learning curve to maintaining your application.
Even if you go the WMI route, PowerShell does have support for working with WMI (though there are a few glitches).
To me, PowerShell is the best way to surface a task oriented interface to an application. With the support Microsoft has been providing PowerShell, it is and will be a consistent interface to managing applications and services throughout the enterprise.
My day job is as an admin and I'm pushing all the vendors I work with towards surfacing a PowerShell management API, as this makes the learning curve and context switching for managing applications much lower. On the development side, I have written (and am still working on) a series of PowerShell cmdlets for one open source product I work with and am working on another set for a separate application.
Jeffrey Snover answers the "why PowerShell" here. The post is in the context of SQL, but very much applicable here.
I'm not sure I'd make the decision. It's not exactly either-or... you can choose to do both.
WMI can be consumed by a number of different things, not just PowerShell. Why not write your management instrumentation in PowerShell, and then wrap that WMI in some task-oriented cmdlets to make things easier on administrators? That's what some MS product teams are choosing to do, especially when they have other consumers of WMI they want to continue supporting.
If you've already got suitable .NET code, turning that into a cmdlet may be faster than turning it into a WMI provider. If that's the case, and speed is a concern, go with what's easier. But no matter what you do, you can always wrap it in a PowerShell cmdlet for admins, which is definitely the recommended approach.
Not sure that this can be answered with the information that you have provided so far. My gut feeling would be that you should use powershell since it sounds like you may already have some .Net code. But it really does just depend on exactly what you are trying to do.
I'll preface this question by saying this is for a Microsoft only shop.
If you were to write a console app to manage a data warehouse what would you use:
1) Writing a custom environment for PowerShell (ala the latest flavors of Exchange / SQL Server)
2) Write it as a C# Console App
If #2 are there any frameworks that offload writing a "menu system" or any other tasks for you.
If this app needed to last 6 to 8 years - would you use PowerShell?
No one on the team currently has PowerShell experience, but we are quick learners.
If you write your management functionality as PowerShell cmdlets, then you can surface that functionality either by letting people run cmdlets directly, or by wrapping them in a GUI. Going with PowerShell probably gives you the most long-term flexibility, and as MS implements more PowerShell cmdlets, it means that managing your data warehouse could be incorporated with other, larger business processes if necessary. I would probably NOT choose to write a C# console app - but I have a distinctly more "administrator" perspective. We admins are tired of having custom console apps tossed at us - the idea of PowerShell is to standardize everything in a way that supports both command-line and GUI administration.
I think you can be successful with both, and should be able to switch between the two without too much hassle. If you start out building a console app but learn PowerShell later, you can throw away a lot of the console app-specific code (command-line parsing code for example) and build a few PowerShell cmdlets to wrap your existing API. Or, if you build a bunch of Cmdlets out the gate, but need to switch to a console app later, you won't have wasted much time writing the Cmdlets.
So, I don't really have strong advice one way or another. I will say: hey, go try PowerShell. If you don't like it, it's not too difficult to switch.
I have found that PowerShell is a much more maintainable solution for smaller things. Console apps require relinking into new libraries and recompiling and redistributing out when the libraries you depend on change (in my case going from Visual Studio 2005 - Visual Studio 2008's codecoverage and other things) as well as executables your scripts may call vsinstr, mstest, etc. where as with PowerShell scripts you can easily customize for each environment you have and don't have to go through the compile, link, deploy stuff for every environment you choose. In fact if you get your path info from the registry the same script can run in both environments.
You can do everything you want with either, I just prefer having to maintain a single simple text file, then a console app. Just personal preference.
When you are saying manage a data warehouse, what kind of tasks are you talking about?
Much of the management I would do in T-SQL (purging, archiving, transforming) - the interface to that can be very thin (even non-existent).
OK, based on your comment I would have the code which does all the work in a stored procs with a .NET assembly (typical API class library), as much in stored procs as possible, with the assembly for stuff which is easier done there or which requires COM or whatever. I would then either wrap the class library in cmdlets or just call the .NET objects from PowerShell (remember that PowerShell can instantiate objects.).
Now you have a .NET library which can also be called from web pages, GUI apps, whatever, if you ever want it, and you have a cmdlet and a direct .NET interface - plus the option of calling them from SQL if they are fully implemented at the SQL layer.
The beauty of implementing PowerShell instead of a cosole app is that you don't have to code all the parameter parsing or all the formatting. PowerShell takes care of all of that for you. You can, of course, override defaults if you need to. You can get wildcards for free. You can also have your Cmdlet(s) take values from the pipeline which opens up all kinds of possibilities and uses for automation. With PowerShell, both the end user and the developer will have a much better experience.