PowerShellAsync - library to build async-enabled PowerShell CmdLets

I love PowerShell.

Yes, I know it is not as good as <insert your favorite shell here>, but on Windows it makes my life easier.

I've been using it for many years now, built my own scripts for easy stuff and CmdLets for more interesting scenarios.   

Lately .NET - based coding starts moving into asynchronous territory with a great speed - most of the modern libraries introduced a Task-based asynchronous API. Using these APIs we can write much more efficient code. And with introduction of .NET 4.5 and async keyword in C#, there are no excuses NOT to write asynchronous code anymore.

Unless you work on a PowerShell Cmdlet.

In typical CmdLet you implement at least one method:

	protected override void ProcessRecord()
	{
	// processing logic
	}

view raw gistfile1.cs hosted with ❤ by GitHub

For more advanced scenarios, focused on processing pipelined data you may also consider implementing these methods:

	protected override void BeginProcessing()
	{
	// before processing of the first item in a pipeline
	}
	protected override void ProcessRecord()
	{
	// process item from a pipeline
	}
	protected override void EndProcessing()
	{
	// after processing of the last item in a pipeline
	}
	protected override void StopProcessing()
	{
	// do cleanup when processing has been aborted
	}

view raw PSA01.cs hosted with ❤ by GitHub

From inside these methods you can interact with PowerShell using a family of Write-* methods like Write-Host, Write-Warning, Write-Verbose, etc.

Also you can ask user to confirm operations using ShouldProcess and ShouldContinue methods.

The only problem is that you can use these methods only from the main thread!

PowerShell validates the stack of the method call and if it is not initiated from one of the 4 primary CmdLet methods, it will throw an exception.

It makes writing asynchronous code using modern libraries a difficult task.
There are many ways to solve this problem, but my goal was to make writing async PowerShell code as easy as a normal one, and have a way to upgrade an existing CmdLet with a minimum effort.

Introducing PowerShellAsync library

First of all, to build a new async-enabled CmdLet or upgrade an existing one, you need to install PowerShellAsync from nuget:

 PM> Install-Package TTRider.PowerShellAsync.dll
(https://www.nuget.org/packages/TTRider.PowerShellAsync.dll/)

And if you curious about implementation, feel free to take a look at the source: https://github.com/ttrider/PowerShellAsync

So now, instead of implementing the original methods, you have to implements their async counterparts! And all of the  Write-* methods will work as if they been called from a main thread!

	protected async override Task BeginProcessingAsync()
	{
	// before processing of the first item in a pipeline
	}
	protected async override Task ProcessRecordAsync()
	{
	// process item from a pipeline
	}
	protected async override Task EndProcessingAsync()
	{
	// after processing of the last item in a pipeline
	}
	protected async override Task StopProcessingAsync()
	{
	// do cleanup when processing has been aborted
	}

view raw PSA01.cs hosted with ❤ by GitHub

So, if you want your CmdLet to execute T-SQL statement on multiple databases at the same time using modern async API, here is your naive PowerShell CmdLet:

	using System.Data.SqlClient;
	using System.Linq;
	using System.Management.Automation;
	using System.Threading.Tasks;
	using JetBrains.Annotations;
	using TTRider.PowerShellAsync;
	namespace PowerShellAsyncExample
	{
	[Cmdlet(VerbsLifecycle.Invoke, "MultiSql")]
	public class MultiSqlCmdlet : AsyncCmdlet
	{
	[NotNull, Parameter(Mandatory = true)]
	public string[] Server { get; set; }
	protected override Task ProcessRecordAsync()
	{
	return Task.WhenAll(
	this.Server.Select(
	server =>
	this.ExecuteStatement(server, "select * from sys.objects")));
	}
	[NotNull]
	async Task ExecuteStatement([NotNull] string server, [NotNull] string statement)
	{
	var connectionBuilding = new SqlConnectionStringBuilder
	{
	DataSource = server,
	IntegratedSecurity = true,
	AsynchronousProcessing = true
	};
	var connection = new SqlConnection(connectionBuilding.ConnectionString);
	await connection.OpenAsync();
	var cmd = connection.CreateCommand();
	cmd.CommandText = statement;
	using (var reader = await cmd.ExecuteReaderAsync())
	{
	if (await reader.ReadAsync())
	{
	var names = new string[reader.FieldCount];
	for (var i = 0; i < reader.FieldCount; i++)
	{
	names[i] = reader.GetName(i);
	}
	do
	{
	var item = new PSObject();
	for (var i = 0; i < reader.FieldCount; i++)
	{
	var value = await reader.IsDBNullAsync(i) ? null : reader.GetValue(i);
	item.Properties.Add(new PSNoteProperty(names[i], value));
	}
	this.WriteObject(item);
	} while (await reader.ReadAsync());
	}
	}
	}
	}
	}

view raw PSA03.cs hosted with ❤ by GitHub

For the complete example, please take a look at Github: https://github.com/ttrider/PowerShellAsync/tree/master/PowerShellAsyncExample

Happy Coding !

Classic Case

As developers, time to time we have to deal with text cases in our code.

Not that we always have to do it, considering that some UI platforms, like HTML/CSS will do this for us:

	<section style="text-transform: none;">This is my test string</section><!-- This is my test string -->
	<section style="text-transform: uppercase;">This is my test string</section><!-- THIS IS MY TEST STRING -->
	<section style="text-transform: lowercase;">This is my test string</section><!-- this is my test string -->
	<section style="text-transform: capitalize;">This is my test string</section><!-- This Is My Test String -->

view raw classic_case_01.html hosted with ❤ by GitHub

To my surprise, I didn't find this same level of support in WFP/Silverlight. Granted, you can mark your <TextBox> with  CharacterCasing="Upper" or "Lower". But no support for Title Case!!! . And no support for other controls, like TextBlock, etc. !

But we play with text cases not only for output. Traditionally some of us do case transformations for case-insensitive compassion, which is wrong on so many levels:

	bool Wrong00(string arg)
	{
	arg = arg.ToLower();
	foreach (var str in mystrings)
	{
	if (str.ToLower() == arg)
	{
	return true;
	}
	}
	return false;
	}

view raw classic_case_01.cs hosted with ❤ by GitHub

First of all, even if you have to use ToLower or ToUpper method, it is a good practice to pass CultureInfo as a parameter. Your server may use one culture, but web request may come with a different culture! By passing culture info into formatting and case transforming methods you ensure that your customers will see what they suppose to see:

	bool Wrong01(string arg)
	{
	arg = arg.ToLower(CultureInfo.CurrentUICulture);
	foreach (var str in mystrings)
	{
	if (str.ToLower(CultureInfo.CurrentUICulture) == arg)
	{
	return true;
	}
	}
	return false;
	}

view raw classic_case_02.cs hosted with ❤ by GitHub

Don't get me wrong, this code is still bad - it is just marginally better then before. First of all, what if arg is null? Or str is null? Sure, we can add those checks, but it will make code even less readable.
Fortunately, .NET provides us with nice alternative: System.String static methods like Equals, Compare, Format, Join, etc.
So our code can look like this:

	bool Better02(string arg)
	{
	foreach (var str in mystrings)
	{
	if (string.Equals(arg, str, StringComparison.CurrentCultureIgnoreCase))
	{
	return true;
	}
	}
	return false;
	}

view raw classic_case_03.cs hosted with ❤ by GitHub

Actually it even runs significantly faster!!! And it is smart enough to take care of special characters !!!:

	var wrongResult = "Straße" == "Strasse"; // false
	var rightResult = string.Equals("Straße", "Strasse", StringComparison.CurrentCulture); // true

view raw classic_case_04.cs hosted with ❤ by GitHub

But if you want to be 100% sure that you are producing the right result, don't rely on System.String.Equals function - use System.String.Compare instead. It takes Culture as a parameter and guaranteed to perform checks according to provided culture rules.

CultureInfo is a very interesting class, it provides you with all information necessary to display your information correctly in different cultures and languages.

Here is the hidden gem that I found that can be used to To Display Dynamic String In Title Case:

	var titlecase = CultureInfo.CurrentCulture
	.TextInfo
	.ToTitleCase(" here is my string in title case");
	// Here Is My String In Title Case

view raw classic_case_05.cs hosted with ❤ by GitHub

So, bottom line:

• Use static methods of the System.String with Culture information for string comparison.
• Use CultureInfo's methods to UpperCase, LowerCase and TitleCase conversions.

Happy Coding!

Shameless plug: if you have to deal with SQL Server performance investigations, try my free web-based tool: http://supratimas.com

All about Lazy

Software Engineers are lazy. It’s a fact.  And it is a good thing.

Lazy engineer would not copy same code over and over, she’ll extract it as a method. Lazy engineer will use a standard .NET feature (tested!) instead of rolling out his own.
Of cause we talk about good engineers. Not so good and lazy engineer will copy code around, causing support nightmare.

BTW, Visual Studio allows you to find this type of code clones: just right-click on the code block and select “Find Matching Clones in Solution”.

Later on, TFS, SVN or GIT will help you to identify those who code like that.

But enough about lazy engineers, today we are going to focus on lazy property initializes.

Let’s take a look at the typical object, that exposes a public property of collection type initialized on-demand:

	class TypicalObject
	{
	private List<string> someStrings;
	public IList<string> SomeStrings
	{
	get
	{
	if (this.someStrings == null)
	{
	this.someStrings = new List<string>();
	}
	return this.someStrings;
	}
	}
	}

view raw potw_1_0.cs hosted with ❤ by GitHub

SomeStrings property would be initialized when it gets accessed for the first time. So far so good.

But imagine you have 5 or 10 properties like that on a class. It is a lot of typing… (remember – lazy!)
There is a way to slightly minimize typing by using ?? operator

The ?? operator is called the null-coalescing operator. It returns the left-hand operand if operand is not null; otherwise it returns the right hand operand. So our property code can be changed like that:


But what if we have to make this property accessor thread safe?

At this point, we have a choice:  we can try to implement thread-safe property initialization yourself, like in this HorrobleObject.
I’m pretty sure I've done it right this time,  but I wouldn't bet on it.

It is possible that I missed some subtle nuance and it is going to bite me later.

So please, don’t use this code.

Fortunately for us, lazy but smart engineers, .NET framework offers the solution:

public class System.Lazy<T>

Using this class we can rewrite our code like this:

	class MuchBetterObject
	{
	private readonly Lazy<List<string>> someStrings =
	new Lazy<List<string>>(
	() => new List<string>(), LazyThreadSafetyMode.ExecutionAndPublication);
	public IList<string> SomeStrings
	{
	get { return this.someStrings.Value; }
	}
	}

view raw potw_1_2.cs hosted with ❤ by GitHub

Lazy object is ideal for a singleton pattern, if you really have to have one.

It allows you to focus on business logic of you class, and not to be sidetracked by low-level details of thread-safe initializers.

Stricktly speaking, Lazy can be used not only in thread-safe scenarious, but in a regular code as well. You can indicate None, as threading mode and in this case Lazy will run without multy-threading overhead.

So, if you need to implement on–demand property initialization in your class, especially in thread-safe fashion, I strongly suggest you to use Lazy<T>!

And if you want to know, what it does under cover, you can take a look at its ~400 lines of code implementation here: http://bit.ly/1gaWjOm

Introduction of the series

Writing code is an exciting business. At least it always been like that to me. It is fast and ever-changing business.

Every day talented people strive toward making software faster, more stable, more secure. And at the same time, even more talented people are looking for ways to break it :-)

Hardware manufactures come up with new components that open up possibilities that were unimaginable just a several years ago. And at the same time these advances make certain ‘industry standard’ patterns and practices dangerous and obsolete.

Keeping up with technology is very important for any kind of engineer, but for The Software Engineer it is an absolute necessity.

Every one of us have a favorite way of doing things and but time to time we have to re-evaluate our coding habits.

In this (hopefully) weekly blog I’m going to illustrate patterns, practices, code snippets that I find interesting, dangerous, cool, exciting ,etc.

Just to illustrate my point, I’m going to give you a simple example. I’m pretty sure that every one of you ​already knows about this coding pattern and never ever write code like that. You don’t, don’t you? ;-)

So, 11 years ago, in .NET 1.1, this snippet was perfectly fine:

	// fine with .NET 1.x
	IDictionary hash = new Hashtable();
	hash["0"] = "a";
	hash["1"] = "b";
	hash["2"] = "c";
	// some code here
	// some code here
	// some code here
	var result = hash["z"];
	if (result != null)
	{
	// do something
	}
	// continue code

view raw gistfile1.cs hosted with ❤ by GitHub

but later, someone decided to upgrade to .NET 2.0 and use modern Dictionary object in initialization. This code still works, as expected:
 

	IDictionary hash = new Dictionary<string, string>();
	hash["0"] = "a";
	hash["1"] = "b";
	hash["2"] = "c";
	// some code here
	// some code here
	// some code here
	var result = hash["z"];
	if (result != null)
	{
	// do something
	}
	// continue code

view raw gistfile1.cs hosted with ❤ by GitHub

But sometime later, when new developer decided to use modern initialization pattern and made a small change to the code, just replaced IDictionary with var: then BOOM, code no longer works:
 

	// let's use var !!!
	var hash = new Dictionary<string, string>();
	hash["0"] = "a";
	hash["1"] = "b";
	hash["2"] = "c";
	// some code here
	// some code here
	// some code here
	var result = hash["z"]; // KeyNotFoundException here
	if (result != null)
	{
	// do something
	}
	// continue code

view raw gistfile1.cs hosted with ❤ by GitHub

The reason code used to work before and not anymore is that implementation of the Dictionary class is backward compatible, when casted into IDictionary interface, but when it is used directly, this class produced an exception, as it supposed to do.

But let's say that you are not aware of this change, and you keep writing code that relies on dictionary to return null, when key is not found. Yes, of cause if you have a solid set of unit tests to cover every line of your code and every possible combination, then you’ll see this problem right away. But we all know that unfortunately it is not a reality and code like that can sneak into production.

So the new, modern code should probably look like this:
 

	var dict = new Dictionary<string, string>()
	{
	{"0", "a"},
	{"1", "b"},
	{"2", "c"},
	}; // inline initializers are SO COOL !!!!
	string value;
	if (dict.TryGetValue("z", out value))
	{
	// do something
	}
	// continue code

view raw gistfile1.cs hosted with ❤ by GitHub

As I said, this example is trivial, but nevertheless important to remember.