Powershell Tutorial Online

So far we have seen native command but now we are going to cross the line and use the Framework more directly

Type in:

PS C:\> [System.Math]::Pow(2, 3)

Look at the sytax..

What you have done is input the System.Math namespace and called the static method Pow().
Get used to the syntax; you will be using it again and again. Square brackets ‘[]’
around the fully qualified type name and two colons ‘::’ indicate
I am calling the static method.
Let us another example, create a variable, set it to a string and then inspect its type.
You may be familiar with the GetType() method from C#.

PS C:\> $abc = "Hello"
PS C:\> $abc.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True String System.Object

Set the variable $abc to a string, it is by using the GetType() method. This is becomes handy when running, tracing and debugging PowerShell scripts. You can find out exactly what type it is.

Send Email from Powershell, create following variables along with create some HTML body` and send it:

$html = "

Html Body

" $Subject = Test Email $SmtpServer = "Localhost" $MailFrom = "" $MailTo = "" Send-MailMessage -Body $html -BodyAsHtml -Subject $Subject -SmtpServer $SmtpServer -To $MailTo -From $MailFrom

With PowerShell v3 toolbox: PSCustomObject. PSCustomObject reduces the amount of code you produce and improves results. In previous versions of PowerShell, you’d use the New-Object cmdlet, passing it a TypeName of PSObject, and a hash table to create an object with properties. New-Object PSObject -Property @{ FirstName = "William" LastName = "Martin" } An unwanted side effect of that you needed additional code to get the properties to appear in the order you wanted: LastName FirstName -------- --------- Martin William PSCustomObject handles this, and in less code: PS> $system = New-Object -TypeName PSObject PS> $system | Get-Member

We’ve focused on keeping you entirely within PowerShell. Everything we’ve shown you to this point has utilized native PowerShell commands, techniques, and capabilities. The sole exception was our brief dip into databases, which required us to utilize the underlying .NET Framework. In that case, we still tried to hide the Framework a bit by providing you with PowerShell-style functions to use for database access. We’ve taken this approach because we truly believe that PowerShell is at its easiest and most consistent when you use it in the way we’ve been doing. In this chapter, we’re going to cross the line and use the Framework more directly. This isn’t an approach that we advocate when you can accomplish your task using native PowerShell capabilities, but we recognize that sometimes you can’t rely solely on what’s built into, and for, PowerShell. There’s a price to pay for using the Framework, though: We’re exiting the somewhat tidy world of PowerShell. There will be no built-in help, and the online documentation we’ll rely on is written for professional programmers, not administrators or scripters. Our PowerShell scripts will necessarily start to look more like C# applications, and we’ll have to rely more on programming techniques than on command-line approaches.