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.
WSH 5.6
As I stated earlier, WSH 5.6 is the primary and most comprehensive scripting environment in Win.NET Server. The WSH version in Win.NET Server is the same version that shipped with Windows XP. So, contrary to what you've read, VBScript isn't going away—it will continue to be with administrators for a long time because many Web sites and applications use VBScript. In fact, more than a dozen of the new command-line tools in Win.NET Server are WSH scripts written in VBScript.
Although the WSH versions in Win.NET Server and XP are the same, several new features in Win.NET Server make WSH all the more powerful. The features include the following:
- Win.NET Server includes a new ADSI Extension for Terminal Services User Configuration. For information about this new extension and sample scripts, see "Rem: Using the ADSI Extension for Terminal Services User Configuration," October 2002, http://www.winscriptingsolutions.com, InstantDoc ID 26365.
- Win.NET Server includes many new Windows Management Instrumentation (WMI) providers, such as the Active Directory Trust, Cluster, and DNS providers.
- When Win.NET Server launches, the new scriptable Group Policy Management Console (GPMC) will be publicly available. GPMC includes several dozen sample scripts that demonstrate how to use WSH to script Group Policy management operations. For more information about the GPMC, see "Introducing the Group Policy Management Console" (http://www.microsoft.com/windows.netserver/gpmc/gpmcintro.mspx).
Keep in mind that WSH and command-line tools aren't mutually exclusive. Administrators sometimes make the mistake of thinking that command-
line tools are only for batch files and COM components are only for WSH. The truth is that WSH 5.6 is a superior environment from which to run command-line tools. For example, WSH can capture and redirect standard input and output (STDIO), perform pattern matching, and monitor a command-line tool's status in ways that batch files can't.
The .NET Framework
If WSH is the primary system administration scripting environment in Win.NET Server and VBScript isn't dead, why are you finding so much information about migrating from VBScript to Visual Basic .NET? The reason is simple: The information you're finding is primarily aimed at component, Web, and application developers, not administrators. That's not to say you shouldn't take a look at the .NET Framework and its three new languages: Visual Basic .NET, JScript .NET, and Visual C# .NET. Several interesting reasons exist to do so, but more about that in a moment. First, let me address how the .NET Framework affects WSH scripting.
The .NET Framework's effect on WSH scripting is this: You can't use VBScript and JScript to access the .NET Framework library. VBScript and JScript (not to be confused with JScript .NET) are what I call COM-classic scripting languages. They're designed to work with COM, Microsoft's mature, reusable component technology. COM, as you probably know, is the magic that lets languages such as VBScript, JScript, and ActiveState's ActivePerl leverage powerful system administration scripting enablers, such as ADSI and WMI.
To programmatically access the .NET Framework, you must use a .NET language. The good news is that for the first time in Windows history, Microsoft included the .NET programming languages and compilers with the .NET Framework. Every Windows platform that has the .NET Framework installed has the basic set of tools and libraries necessary to write .NET programs. You don't have to buy Visual Studio .NET to use the .NET Framework. However, Visual Studio .NET certainly makes using the .NET languages a lot easier.
The bad news is that the .NET Framework doesn't have a .NET scripting environment or language, which raises the question, "What is a scripting language?" From a traditional computer-science perspective, scripting languages are high-level languages that you primarily use to glue things together. Take WSH and VBScript, for example. You primarily use WSH (a scripting environment) and VBScript (a scripting language) to glue together prebuilt COM components and command-line tools to achieve a desired result.
Scripting languages are also characterized by their runtime behavior and ease of use. For example, scripting languages are generally interpreted, which means you don't have to compile a script—you just write and run it. Scripting languages make development easier and faster by removing programming idioms commonly associated with system-level programming languages. For example, you don't have to declare variables or worry about data types unless you want to. The result is a relaxed programming environment that lets administrators focus more on the task and less on the programming specifics.
The three new .NET languages (i.e., Visual Basic .NET, JScript .NET, and Visual C# .NET) don't neatly fit into the traditional scripting language mold. They're strongly typed (i.e., data types are required), early bound (i.e., object and data type information is determined at compile time rather than at runtime), compiled programming languages. This might or might not matter to you. Just be aware you're going to have to deal with a few more programming idioms than you do when you use a scripting language such as VBScript.
Perhaps the more important question is, "Why would you want to access the .NET Framework from system administration scripts?" After all, if you have scripts that work, why change? One reason is that you can gain many benefits that the .NET Framework's Common Language Runtime (CLR) provides. But the most compelling reason is that the .NET Framework library will provide comprehensive access to the entire Windows platform. The days of not being able to automate an administrative task because of a limitation in the scripting environment will be a thing of the past.
So where do you go from here? The Windows platform is in a period of transition. Although Microsoft has made great progress on the .NET Framework library, it still has a ways to go. As is typically the case in the IT world, developers often lead transitions, while administrators typically wait for the dust to settle. My advice to you is to stay where you're at scripting-wise. As time permits, ramp up on the .NET Framework and tinker with one of the .NET languages. If Microsoft provides a .NET-savvy system administration scripting solution, you'll be in a good position to run with it. And if not? Well, you'll at least have started down the .NET path.
