.NET Developers Taking to PowerShell

Scripting in the .NET-based PowerShell saves developers time and leverages their Microsoft platform expertise.

As a developer and technical lead for a large New York financial services company, Scott Weinstein initially tinkered with a beta version of Microsoft's new Windows PowerShell command-line interface last year to create aliases for some common project scenarios in MSBuild.

It wasn't long before Weinstein, like a growing number of enterprise developers, was scripting almost exclusively in the .NET-based PowerShell to save time and leverage his Microsoft platform expertise. "The interconnection with the .NET framework made PowerShell a lot more compelling than a Perl or Python," he says.

PowerShell, which will be bundled into the forthcoming Windows Server "Longhorn," was largely designed for systems administrators. But observers say it's also catching on among .NET developers as a replacement for VBScript and a host of non-Microsoft scripting languages.

Building on PowerShell
Windows Management Partner Architect Jeffrey Snover, who has been informally tracking PowerShell's uptake among programmers by searching technology blogs and following third-party PowerShell extension projects, figures developers account for roughly half of the 800,000 PowerShell downloads logged since the November release.

"Developers are saying, 'Hey, this is great, but we want to write cmdlets to do PV headers for files, cmdlets to do various security things,'" Snover says. "Other projects are doing graphic hosts to PowerShell so you can run it outside the console itself, as well as producing IDEs, script debuggers, script editors and syntax files for editors. There're quite a few."

Karl Prosser, a developer working on a product called PowerShell Analyzer, an alternate, more robust interface for the command-line tool, says he often didn't bother to write time-saving automation scripts for his projects before PowerShell. That's because he finds Perl and similar languages too object-centric for the Windows platform, and he'd rather not deal with runtime errors in VBScript.

"But with PowerShell and PowerShell Analyzer you can run a few lines of script at a time and see how that behaves and then just sculpt something from there over time," Prosser says.

Weinstein says PowerShell is gaining traction throughout his Manhattan firm, mainly among developers who have some background working with Unix or Oracle databases.

"If we need to create a feed and send it to some other system using FTP and files, that's all done now through PowerShell. In New York, in the financial services world, people are definitely aware of it," Weinstein says. "But since it's only available for XP and above, that's hurt adoption. A lot of shops are still on Windows 2000."

Microsoft's Snover says programmers also are looking at embedding PowerShell into applications.

"An example is a management GUI, but it's entirely layered on top of PowerShell. You see more and more of these coming out," Snover says. "It ensures that everything in the GUI can be done in the command line."

All in One
The first release candidate of Prosser's PowerShell Analyzer interface and IDE hit the Web late last month. Prosser says he envisions his tool as the PowerShell equivalent of the SQL line analyzer in Visual Studio.

Whether .NET developers interact with PowerShell from the command line or in a modern, GUI interface, Snover expects it to free them from the need to master multiple languages from different platforms to do their jobs.

"It used to be you had to be a shell programming expert, but that didn't help you with scripting. And if you became a Perl programming expert, it didn't help you with your systems programming or your shell programming," Snover says. "It was a completely unintegrated environment. Whereas with PowerShell, it's all entirely .NET-based. When you type a command, you're getting a pipeline to .NET objects."
comments powered by Disqus
Upcoming Events

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.