I'm researching the Microsoft .NET Framework's effect on scripting. I've been using Windows Script Host (WSH) and VBScript for some time. However, based on the information I've been able to gather, it appears that VBScript is going away. For example, in "VBScripting Solutions: A Look at .NET and Its Impact on Scripting" August 2001, http://www.winscriptingsolutions.com, InstantDoc ID 21568, Dino Esposito writes, "Visual Basic .NET replaces VBScript, so VBScript users should start learning Visual Basic .NET." I've found similar remarks in other online resources. For example, a Microsoft PowerPoint presentation on the ASP 101 Web site (http://www.asp101.com/articles/john/migration/slides/migrating_to_aspnet.ppt) states, "VBScript is now full blown VB" and goes on to say, "VBScript is gone (really)." These comments are troubling because I'll have to migrate all my WSH scripts to Visual Basic .NET. Can you shed any light on Microsoft's scripting strategy and recommend where I should focus my efforts?
Excellent question—I'll try to explain the .NET Framework's effect on scripting based on what I know. The first order of business, however, is to put your question into context—that is, to clarify whether you're talking about traditional system administration scripting (using shell, WSH, Perl, or other types of scripts for task automation), Web development, component development, or application development. I assume you're talking about traditional system administration scripting because that's the focus of Windows Scripting Solutions.
For system administration scripting in Windows .NET Server (Win.NET Server) 2003, Microsoft's primary and most comprehensive scripting solution continues to be WSH 5.6, which includes VBScript and JScript. To be completely on the up-and-up, Microsoft is attacking system administration task automation on two fronts in Win.NET Server: command-line tools and WSH. I'll briefly review each initiative, then address the .NET Framework part of your question.
Command-Line Tools
As I write this answer, Win.NET Server Release Candidate 1 (RC1) includes 61 new command-line tools. For the complete list, see the Help and Support Center topic titled New command-line tools in Win.NET Server RC1 (or later). In addition to adding new tools, Microsoft improved many of the command-line tools included with the OS. Some of the improvements include the following:
- A consistent set of command-line switches. For example, /S followed by a computer name specifies the target computer. Similarly, /U and /P are used to specify a user context and password, respectively.
- Setting the %ERRORLEVEL% environment variable to show success or failure.
- Support for remote operations.
Although the command-line tools definitely fill a void, they have some shortcomings. For example, the six new Active Directory (AD) command-line tools (dsadd.exe, dsget.exe, dsmod.exe, dsmove.exe, dsquery.exe, and dsrm.exe) don't support all AD objects. Nor do they support all attributes for the objects they do support. As a result, if you're looking for the most comprehensive AD scripting solution, using WSH, VBScript, and Microsoft Active Directory Service Interfaces (ADSI) is your best bet. If you think ADSI is too hard to learn, the six new AD tools are worth checking out.
While I'm on the topic of command-line tools, I should point out that Microsoft hasn't changed the command shell (cmd.exe) as far as I know. So, if you're writing batch files, I have no major shell improvements to report. However, a few of the new command-line tools are specifically designed to enhance the capabilities of batch files. For example, the OS now includes old favorites, such as choice.exe and forfiles.exe.
Prev. page
[1]
2
next page 
