Microsoft .NET Framework Essentials

.NET is Microsoft's leading-edge software development framework. Traditional .NET development begins inside a development environment like Microsoft Visual Studio, SAPIEN PrimalScript Enterprise, or even Windows Notepad. After applications are written in languages like Visual Basic .NET or Visual C#, they're compiled to a special language called the Microsoft Intermediate Language (MSIL). This is important, because it's different from how other things such as Visual Basic 6 compiled programs into a native, binary executable.

When you double-click a .NET executable, it doesn't run right away because it contains MSIL, not actual binary code. Instead, Windows fires up the .NET Common Language Runtime (CLR), which is what reads the MSIL and compiles it into executable, binary code that will run on your system. This makes .NET applications inherently portable since they can (more or less) run on any platform for which a CLR is available. This is all a bit of an oversimplification, but it's more than close enough for Windows administrative work.

The point of all this is that PowerShell is built on .NET, as are the cmdlets you'll be running. .NET is what's called an object-oriented framework, which is a fancy way of saying it is kind of template-based. For example, all PowerShell cmdlets start out as copies of a standardized cmdlet base class or template. In programmer terms, you'd say that all cmdlets inherit from that cmdlet base class. This is important because it's what makes all cmdlets pretty consistent with one another, which allows them to share certain ubiquitous parameters, etc.

The object-oriented stuff plays heavily into how PowerShell works, which is why you need to know a bit more about what an object is. At the simplest level-perhaps a level suitable for cocktail parties-an object is a bunch of computer code bundled into a "black box." The black box has buttons you can push to make things happen, and it has little blinking lights to tell you what's going on inside. You don't actually know how the box works-inside it could be anything from a particle accelerator to a cheese sandwich. But that doesn't really matter since the point is that you only interact with the box through its blinking lights and buttons while everything inside remains a big mystery. You can build your own black box that incorporates another black box, which is called inheritance. Essentially inheritance occurs when you install box number one inside box number two, so box number 2 can take full advantage of box number one's functionality without knowing much about what goes on inside.

Everything is an object in .NET and in PowerShell. Every variable you create, every WMI class you return - everything is an object. All of these objects have buttons called methods and blinking lights called properties. For example, when you run the code listed below, the Get-Wmiobject cmdlet gets all the instances of the Win32_Process WMI class.

 PS:> $stuff = get-wmiobject –class Win32_Process  -namespace root\cimv2 

Each instance of the Win32_Process WMI class is an object. Together, the instances are bundled into a collection of objects that is stored in $stuff. The collection itself is an object.

Note 

You can think of a collection as a bucket that is an object you can do things to. This bucket can also contain other independent objects. Sometimes a collection is referred to as a list or array. Arrays will be discussed in greater detail in the next chapter.

So, the variable $stuff is now a collection of Win32_Process instances. Even a simple string of text "like this one" is really an object-specifically a string object-as far as PowerShell and .NET are concerned.

Reflection

Microsoft's Component Object Model (COM) is the pre-PowerShell way of managing Windows, often through a language like VBScript. Part of what made COM so difficult was that objects had to take special steps to define their functionality ahead of time. In other words, when someone at Microsoft created a DLL that allowed your scripts to work with files and folders, they also had to create a little file called a type library that explained the capabilities of the DLL. That made COM difficult to extend in certain ways, and certainly made it tough to use.

On the other hand, with .NET there's a nifty feature called reflection. Basically, reflection is a way for one application like PowerShell to discover something about an object at runtime without being told in advance what the object can do. Reflection makes PowerShell infinitely extensible because you can add new cmdlets. PowerShell can also, more or less, ask the cmdlets what they do and how they work.

Reflection makes PowerShell easier for you to use. For example, if you don't know what capabilities an object has, just pipe an instance of it to the Get-Member cmdlet. This cmdlet uses reflection to display all the known properties and methods of the object within PowerShell.

Assemblies

In .NET, everything eventually gets packaged into an assembly, which is a fancy word for what we otherwise call an executable, DLL, or some other file-that-contains-executable-code. You'll find assemblies distributed with PowerShell by default in the shell's installation folder.

Note 

One assembly can contain or implement multiple objects or interfaces-each one being a separate cmdlet, for example)

For example, System.Management.Automation.Commands.Management.dll is a file containing bunches of different cmdlets.

Classes

The .NET Framework, and also PowerShell, treats almost everything as an object. However, different objects can be expected to have different functionality. For example, a car object has different capabilities than an airplane object. The Framework defines classes to distinguish between object types. A class is an abstract description of an object's capabilities. The name of a class is often referred to as its type. So a string variable is more accurately referred to as "an object of the System.String type" or "an object of the System.String class." String objects have some distinct capabilities such as the ability to return an uppercase version as shown in the following code:

 PS C:\> $a = "hello" PS C:\> $a.ToUpper() HELLO PS C:\> 

Or the ability to display their length:

 PS C:\> $a = "world" PS C:\> $a.Length 5 PS C:\> 

Don't Forget the ()

This is a great time to point out a difference between methods and properties. In the above two examples, notice that the method ToUpper() must be executed with parentheses, even though it doesn't have any arguments. The property Length, on the other hand, doesn't use parentheses. If you forget to add the parentheses to a method, it won't run properly. We forget all the time, and it can be very frustrating until you develop the proper typing habits!

The Framework exposes most of Windows' functionality such as the ability to display graphical dialog boxes as classes. For example, if you create a new instance of the Windows.Forms.Form class, you're creating a new, blank window or dialog box. You'll see how to use this in the next section. The important thing to remember right now is that the .NET Framework is comprised entirely of these classes. Knowing how to work with them can give you a lot of capabilities in PowerShell. Even if you don't work with advanced classes like Windows forms, you can still work with basic classes like String, Int32 that let your scripts manipulate data more easily.

Advanced .NET in PowerShell

The Framework has an unbelievable amount of functionality built into it, and PowerShell exposes almost all of this functionality. While you may never want to, you can leverage this functionality anytime. For example, a major shortcoming of VBScript was that it featured very minimal user interface capabilities. Not so with PowerShell that can draw on the entire .NET Framework for user interface features. The Framework includes classes for something called Windows Forms, which are the bits of the Framework used to construct graphical Windows applications. Ryan Paul at Arstechnica.com found that the Windows Forms classes contained in a .NET assembly named System.Windows.Forms can be utilized from within PowerShell:

 PS C:\> [Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") GAC    Version        Location ---    -------        -------- True   v2.0.50727 C:\WINDOWS\assembly\GAC_MSIL\System.Windows.Forms\2.0 PS C:\> $window = new-object Windows.Forms.Form PS C:\> $window.text = "This is a dialog box!" PS C:\> $button = new-object Windows.Forms.Button PS C:\> $button.text = "Close" PS C:\> $window.controls.add($button) PS C:\> $window.showDialog() 

This loads the System.Windows.Forms assembly into PowerShell. It then uses the New-Object cmdlet to create a new object of the Windows.Forms.Form type, and assign a value to the resulting object's Text property. It then creates a new Windows.Forms.Button object, assigns a value to its Text property, and adds the button to the window's Controls collection. Finally, it calls the window's ShowDialog() method with the result shown in Figure 4-1.

Figure 4-1: Displaying a dialog box in PowerShell

No code was added to the button, but if the red "X" icon us clicked to close the window, PowerShell displays "Cancel" as a result of the ShowDialog() function. This might not be something you use everyday, but it's a powerful capability to know about in case you ever need it.