I’m very excited to announce that exactly one month from today will be the first meeting of the Charlotte PowerShell Users Group.  Moreover, I’m giddy with anticipation as this first meetup will play host to Ed Wilson of the Microsoft Scripting Guys blog and “the Scripting Wife” Teresa!

We’ll be meeting at the Charlotte Microsoft campus at 6pm on January 5, 2012.  The schedule for this meeting is roughly as follows:

• 6:00 – 6:30 pm: arrive and socialize.
• 6:30 – 7:00 pm: sponsors, group roundtable.
• 7:00 – 9:00 pm: Ed Wilson discusses PowerShell Best Practices

If you are near Charlotte, North Carolina and use PowerShell in any capacity, I encourage you to join the group and attend this meetup.  Not only will you reap the benefits of Ed’s talk, but you’ll help shape the group to best serve the local PowerShell community!

I’ve been reading the book Ghost in the Wires by social-engineer-extraordinaire Kevin Mitnick.  The book is completely engrossing, and I’ve been enjoying the story so much I had to tweet about it:

Reading Ghost in the Wires by Kevin Mitnick. Absolutely mesmerizing account of simple and effective social engineering exploits.

… and as it happens on twitter, Mr. Mitnick happened to be wading in the conversation flow and replied:

glad you liked it. Please put your comments on Amazon for me.

… and as it also happens on twitter I wrote a knee-jerk reply:

surely I will. Also will purchase some of your other books. Also, please don't steal any of my digital identity stuff, k?

…and as it usually comes to pass I then imagined the whole of my twitter following offering up a rowdy “har-dee-har-har” and I got back to work.

… and then I started to get deeper into the book. 

… and I started to get a feel for the raw deal that Mr. Mitnick has received. 

… and I thought back to my attempt at humor (see the underlined portion of my last tweet, above) and realized with some statistical certainty just how many times Mr. Mitnick has had to endure crap like that from rubes like myself.

Hey, I’m under no illusion that my comment had any effect on the man.  However, an apology is in order, if only to serve as a self-reminder not to tweet without thinking.

So, Mr. Mitnick, if you happen to find this:

I sincerely apologize for my off-hand and thoughtless attempt to be cute.  The only rectification I can offer is a promise to apply more mental processing to my tweets from this point forward. 

If it’s any consolation, the overly-intimate relationship between corporate IT policy and law is something I think about quite often. 

… and worry about.

… and occasionally blog about. 

… and try to avoid altogether really.

I mean, seriously – corporations aren’t culpable for willingly exposing data on a public network but the individual is at fault for looking at it???!!1  For the love of Pete… 

There is no shortage of code generation techniques available in Visual Studio.  There are even some neat PowerShell solutions that are based on the DTE.  Let me show you an approach I’ve used a few times – it’s a fairly special case, but it’s one of those problems that requires a high volume of monkey code that I frankly don’t want to spend a lot of time on.  It also demonstrates a few automation techniques you may not have considered before – such as driving other Visual Studio extensions like ReSharper.  My hope is that it gives you some fodder for exploring your own creative automation solutions with StudioShell.

The scenario: I need to take a COM interface and wrap it in a .NET class.  Why?  Long story for another post, but it has to do with getting PowerShell format definitions working for said COM interfaces. 

For example, I’ve recently been working on a PowerShell Provider around the Windows Task Scheduler.  The Task Scheduler API is COM-based and consists of a handful of about 40 interfaces that need wrapping to work in my provider framework.

My standard workflow to create one of these wrappers is fairly wrote at this point:

1. Define the wrapper class in C#;
2. Add a private field holding a reference to the COM interface;
3. Initialize the field in the wrapper class constructor;
4. Use ReSharper’s Generate Delegating Members code generation feature to recreate the COM interface implementation in C#.

Not hard, but lots of easy that needs to get done.  First I’ll show how I accomplish this manually, then at how StudioShell can take the pain out of this boring work…

Manual Workflow

Here is how I would implement the wrapper for the simple IAction interface in the Task Scheduler COM type library.  The COM interface is defined as follows in C# code:

 1 public interface IAction
 2 {
 3     string Id
 4     {
 5         get;
 6         set;
 7     }
 8 
 9     _TASK_ACTION_TYPE Type
10     {
11         get;
12     }
13 }

Step 1: Define the wrapper class in C#

The C# wrapper classes I create are usually named after the interfaces by replacing the “I” in the interface name with “Shell”.  So, IAction becomes “ShellAction” in implementation:

1 public class ShellAction
2 {
3 }

Step 2: Add a private field holding the COM reference

With a basic class structure in place, I add a private field holding the IAction reference:

1 using TaskScheduler;
2 
3 public class ShellAction
4 {
5     IAction _item;
6 }

Step 3: Initialize the COM reference in the class constructor

The IAction _item field needs to be initialized in the class constructor:

1 public class ShellAction
2 {
3     IAction _item;
4 
5     public ShellAction(IAction item)
6     {
7         _item = item;
8     }
9 }

And to be honest, I don’t write this code – I use ReSharper to generate it for me.  I hit [alt]-[insert] and ReSharper pops up a list of code generations it can perform on the class, and I select Generate Constructor, and it does the magic for me.

Step 4: Generate delegating members using ReSharper

Once the basic class and field code is in place, I turn again to my second-favorite Visual Studio extension.  ReSharper ships with a badass function called “Generate Delegating Members” that does exactly what the name implies – it can generate method and property calls that forward to a class member.

Using a dialog to allow me to select what members I want to create delegating calls for, and once I click Finish to run this little gem, the class is code complete:

 1 public class ShellAction
 2 {
 3     IAction _item;
 4 
 5     public ShellAction(IAction item)
 6     {
 7         _item = item;
 8     }
 9 
10     public string Id
11     {
12         get { return _item.Id; }
13         set { _item.Id = value; }
14     }
15 
16     public _TASK_ACTION_TYPE Type
17     {
18         get { return _item.Type; }
19     }
20 }

Rocket science it ain’t.  Still, I have about 39 more of these things to create.  Time to automate.  Heh.  Poetry.

Automated Workflow

In a nutshell, I want to use StudioShell to drive this four step process for each interface in the Task Scheduler type library.  So, the first thing I need is a list of every interface I can find in that type library.  This is pretty easy to do since PowerShell has access to the entire .NET underpinnings:

1 §> $t = [appdomain]::currentdomain.getassemblies()`
2      | where { $_.fullname -match 'tasksch' } `
3      | %{ $_.gettypes() } `
4      | where { `
5        $_.isinterface -and $_.name -match 'i' `
6      }

This pipeline looks complicated, but it’s pretty simple when you break it down.  In English, it reads as “From all loaded assemblies (line 1) whose fullname contains the string ‘tasksch’ (line 2) get the public types (line 3) that are interfaces and start with the letter ‘I’ (line 5).”  The goal is to get the public interfaces from the Task Scheduler type library.  The results are stored in the variable $t, which contains what we expect:

1 § >$t
2 
3 IsPublic IsSerial Name
4 -------- -------- ----
5 True     False    ITaskFolderCollection
6 True     False    ITaskFolder
7 True     False    IRegisteredTask     
8 True     False    IRunningTask
9 ...

Cool.  Now we have the list of interfaces we need to wrap.  Let’s start hacking.

Step 1: Define the wrapper class in C# ( 40 times )

To keep things simple, I’m going to dump all of these generated classes into a single new code file.  I can always break them out later if I choose to.  I navigate StudioShell to the project I’m working in:

§ >cd DTE:\solution\projects\scheduledtasks

and create a new code file:

§ >new-item -type codefile -name test.cs

Then I navigate StudioShell into the code model for this new empty file:

§ >cd ./test.cs/codemodel

Time to bring the awesome.  I want a new public class for each interface in $t, and I want the class name to be the same of the interface with the initial 'I’ replaced with “Shell”:

§ >$t | foreach { new-item -type class `
    -name ($_.name -replace '^I','Shell') `
    -access public }



    Location: dte:\...\test.cs\codemodel
    File: test.cs
    Code Container: 
    Available Operations: d+ <      


Kind                     Name
----                     ----
vsCMElementClass         ShellTaskFolderCollection
vsCMElementClass         ShellTaskFolder
vsCMElementClass         ShellRegisteredTask
...

Taking a quick peek at the code now in test.cs, it would seem I have my 40 classes declared:

public class ShellTaskFolderCollection
{
}

public class ShellTaskFolder
{
}

public class ShellRegisteredTask
{
}

// ...

Step 2: Add a private field holding the COM reference ( 40 times )

Next item we need is the private COM reference in each class.  I can accomplish this using the standard new-item cmdlet to create private member variables inside of each class:

 1 § >$t | foreach { `
 2   $c = $_.name -replace '^I','Shell'; `
 3   new-item -path $c `
 4     -name _item `
 5     -membertype $_.name `
 6     -type variable }                                      
 7 
 8     Location: dte:\...\test.cs\codemodel\
 9     File: test.cs
10     Code Container: Class ShellTaskFolderCollection
11     Available Operations: d+ <      
12 
13 
14 Kind                     Name
15 ----                     ----          
16 vsCMElementVariable      _item
17 
18 ...

For each interface in $t, I derive the class name using the same replace logic I used in step 1; I store this class name in the variable $c (line 2).  My current location is the code model for the test.cs file, so I can use this class name as a relative path to the new-item cmdlet to create class members.  In lines 3-6, I do just that to create a private field named “_item.”  The type of field _item is set to the name of the Task Scheduler interface being processed.

Huh, looking at the code file I can see I need to add a using statement to let the compiler resolve those TaskScheduler type library references; I’ll just do that by hand to get it done:

using TaskScheduler;

public class ShellTaskFolderCollection
{
    ITaskFolderCollection _item;
}

public class ShellTaskFolder
{
    ITaskFolder _item;
}

public class ShellRegisteredTask
{
    IRegisteredTask _item;
}
//...

So far so good.

Step 3: Initialize the COM reference in the class constructor ( 40 times )

Now things get interesting.  I need to add a constructor that initializes the value of the COM reference.  I used ReSharper to do this before, but there’s no way to automate ReSharper is there?  Um, yeah, there is.

All Visual Studio extensions (and Visual Studio itself) expose handles to their functionality in the form of Command objects.  StudioShell dutifully exposes these commands as part of the DTE: drive.  If we can find the command, we can pass it to the standard invoke-item cmdlet to make it run.

So let’s find the command.  Knowing that it’s a ReSharper command, and that it has something to do with generating constructors, I can narrow my search using intuition:

§ >ls dte:/commands | where {`
   $_.name -match 'resharper' `
     -and `
   $_.name -match 'constructor' }


    Location: dte:\commands
    Available Operations: d+ <      


Name
----
ReSharper.ReSharper_Constructor2FactoryMethodAction
ReSharper_Generate_Constructor

Hmmm, I’m not a betting man, but I’d still put money that the ReSharper_Generate_Constructor command is the one I’m after.

Now, a little Visual Studio SDK sidebar – when a command executes, it uses the context of the current user activity.  In the case of this particular ReSharper command, it will only execute successfully if I’m currently in a code editor window working on a class.  Moreover, I need to move the cursor to the class I want the command to operate on.  Starting to sound like more trouble than its worth?

Fear not grasshopper – StudioShell has your back yet again!  One of the newer features of StudioShell is the ability to “navigate” to specific code model elements using the invoke-item cmdlet.  This is a recent feature that will be available in the upcoming 1.2 release.

So back on track, we want to invoke the ReSharper_Generate_Constructor command on each of our classes in test.cs.  So, that’s what we do:

1 § >ls -recurse | where {$_ -match 'class' } | foreach {
2   $_ |invoke-item; 
3   invoke-item `
4     dte:/commands/ReSharper_Generate_Constructor
5   }

Line 1 isolates the classes in test.cs; each class code item is first “invoked,” causing the containing document to activate and the cursor to move to the class code (line 2), then the ReSharper Generate Constructor command is invoked (lines 3-4). 

The result – the ReSharper Generate Constructor dialog is opened once for each class.  Unfortunately there is no way I know of to automatically select what members to initialize and then dismiss the dialog.  I’m sure there is, and I’d love to hear about it in the comments.  But right now I’d rather be more done than smart.  So, I hit [space]-[enter] 40 times like a schlep.

And the code looks right:

 1 using TaskScheduler;
 2 
 3 public class ShellTaskFolderCollection
 4 {
 5     ITaskFolderCollection _item;
 6 
 7     public ShellTaskFolderCollection(ITaskFolderCollection item)
 8     {
 9         _item = item;
10     }
11 }
12 
13 public class ShellTaskFolder
14 {
15     ITaskFolder _item;
16 
17     public ShellTaskFolder(ITaskFolder item)
18     {
19         _item = item;
20     }
21 }
22 
23 public class ShellRegisteredTask
24 {
25     IRegisteredTask _item;
26     
27     public ShellRegisteredTask(IRegisteredTask item)
28     {
29         _item = item;
30     }
31 }
32 
33 // ...

Step 4: Generate delegating members using ReSharper ( 40 times )

One last step and I’m done.  I need to run the ReSharper Generate Delegating Members command on each class.  This isn’t that different from what I had to do in step 3, and since I’ve taken the mystique out of automating ReSharper I know exactly what to do.

First, find the command.  I’ll use the same intuition that worked for me in step 3:

 1 § >ls dte:/commands | where { `
 2   $_.name -match 'resharper' `
 3   -and `
 4   $_.name -match 'delegat' }
 5 
 6 
 7     Location: PSDTE::dte:\commands
 8     Available Operations: d+ <      
 9 
10 Name
11 ----
12 ReSharper_Generate_Delegating            

Well lookey what we have here…  Hello there ReSharper_Generate_Delegating command!  Prepare to be automated!

This command works like the ReSharper_Generate_Constructor command – input focus has to be in a class code element in a text editor window.  But after solving step 3 this is no issue.  In fact, the solution for step 4 looks almost identical to step 3:

1 § >ls -recurse | where {$_ -match 'class' } | foreach {
2   $_ |invoke-item; 
3   invoke-item `
4     dte:/commands/ReSharper_Generate_Delegating
5   }

The only thing I had to change was the name of the command.

Again I get about 40 dialogs, one for each class, asking me what fields I want to create delegating members for, and as before I just type [space]-[enter] until the UIs disappear.

The code looks accurate:

 1 using TaskScheduler;
 2 
 3 public class ShellTaskFolderCollection
 4 {
 5     ITaskFolderCollection _item;
 6 
 7     public ShellTaskFolderCollection(ITaskFolderCollection item)
 8     {
 9         _item = item;
10     }
11 
12     public IEnumerator GetEnumerator()
13     {
14         return _item.GetEnumerator();
15     }
16 
17     public int Count
18     {
19         get { return _item.Count; }
20     }
21 
22     public ITaskFolder this[object index]
23     {
24         get { return _item[index]; }
25     }
26 }
27 
28 public class ShellTaskFolder
29 {
30     ITaskFolder _item;
31 
32     public ShellTaskFolder(ITaskFolder item)
33     {
34         _item = item;
35     }
36 
37     public ITaskFolder GetFolder(string Path)
38     {
39         return _item.GetFolder(Path);
40     }
41 
42     public ITaskFolderCollection GetFolders(int flags)
43     {
44         return _item.GetFolders(flags);
45     }
46 
47     // ...
48 }
49 
50 public class ShellRegisteredTask
51 {
52     IRegisteredTask _item;
53 
54     public ShellRegisteredTask(IRegisteredTask item)
55     {
56         _item = item;
57     }
58 
59     public IRunningTask Run(object @params)
60     {
61         return _item.Run(@params);
62     }
63 
64     public IRunningTask RunEx(object @params, int flags, int sessionID, string user)
65     {
66         return _item.RunEx(@params, flags, sessionID, user);
67     }
68 
69     //...
70 }
71 
72 // ...

… and it even builds (read: SHIP IT!!).  2500+ lines of monkey code created in 5 lines of powershell, all in all about 10 minutes of exploring. 

Hindsight

This little demo show some pretty powerful automation techniques – honestly I find the notion of automating other automation tools compelling.  A few things I’d like you to keep in mind as you explore your own automations:

1. I’m automating my workflow, not my coding.  That is, my focus is on replicating the activities I do manually in Visual Studio to yield the code I want in the end.  In this case that means driving another automation tool.  I’m not looking for fancy or even “best practice” with this, I’m looking for done. 
2. I’m not plotting a general solution I plan to reuse.  Sure I’ll employ some of the techniques again, but it’s actually easier (for me at least) to treat each new workflow as a new automation opportunity.  Moreover, trying to generalize this solution now would be a waste of time, since experience tells me that the next situation will be just different enough to force me to change my approach.
3. I don’t focus on automation alone – that is, when I encounter a simple snag – such as the missing “using TaskScheduler;” statement in the code file, I just fix it by hand and move on instead of revisiting my automation technique to make it work perfectly.
4. I’m automating something I’ve done manually several times.  So I have clear expectations of what needs doing and the path to follow.  My rule of thumb is not to automate until I can recite the steps I’ve taken before my memory.

Enjoy!

In the last few talks I’ve given on PowerShell for Developers, I’ve focused on build, test, and code automation.  When discussing StudioShell, I’ve pulled a very effective demo from a real-life project…

After wrapping up an iteration with a client, they returned to me with a new 300,000-line code base spread over about 200 (very messy) files.  They were in the process of implementing a set of “corporate” coding standards and wanted some help getting their existing codebase to these standards.

One standard in particular was that and property that meets these criteria:

1. is public
2. returns a boolean

should start with “Is”.  So in this example code:

public class Demo 
{
   public bool Enabled { get;set; }
   public bool Valid { get;set; } 
   public bool IsRunning { get;set; } 
   public string Name { get;set; } 
   private bool Applied { get;set; } 
}

The properties Enabled and Valid need to be renamed to IsEnabled and IsValid (lines 3 & 4).  The IsRunning property already meets the standard (line5), the Name property returns a non-boolean type so the standard doesn’t apply (line 6), and the Applied property is private and excluded from the standard.  In the end this file needs to look as follows:

public class Demo 
{ 
   public bool IsEnabled { get;set; }
   public bool IsValid { get;set; } 
   public bool IsRunning { get;set; }
   public string Name { get;set; }
   private bool Applied { get;set; }
}

While it’s entirely possible to apply this standard by hand, the thought of scouring 300,000+ lines of code for properties that meet this criteria is not an attractive task.  FxCop can probably find these properties for us, but it can’t apply a fix – that still requires human intervention.  Best case scenario, I’m looking at days of mind-numbing monkey-on-a-keyboard work.

This is the kind of problem that screams for automation.  This is where StudioShell shines.  Here’s how I slashed through this Gordian knot…

First, I isolated a single code file in my StudioShell console, so I could work out the pipeline logic I needed without obliterating the codebase:

> cd DTE:\solution\codemodel\demoapp\program.cs

Second, I use PowerShell’s filtering capabilities to isolate all public properties in the file:

# spacing added for readability
> ls -recurse | where { 
     $_-match 'property' -and
     $_.access -match 'public' }

Location: dte:\solution\codemodel\demoapp\program... 
File: program.cs 
Code Container: Class Demo 
Available Operations: d+ < 
        Kind                         Name 
-----  ----                          --------- 
d+ < vsCMElementProperty Enabled 
d+ < vsCMElementProperty Valid 
d+ < vsCMElementProperty IsRunning 
d+ < vsCMElementProperty Name

#spacing added for readability
> ls -recurse | where { $_-match 'property' -and
    $_.access -match 'public' -and
    $_.type.asFullName -match 'bool' } 

Location: dte:\solution\codemodel\demoapp\program... 
File: program.cs 
Code Container: Class Demo 
Available Operations: d+ < 

        Kind                         Name 
        --------------              ---- 
d+ < vsCMElementProperty Enabled 
d+ < vsCMElementProperty Valid 
d+ < vsCMElementProperty IsRunning

The last factor to consider is the property name – I only need names that do not start with “Is”.  Easily done:

#spacing added for readability
> ls -recurse | where { $_-match 'property' -and
   $_.access -match 'public' -and
   $_.type.asFullName -match 'bool' -and
   $_.name -notmatch '^Is' } 

Location: dte:\solution\codemodel\demoapp\program... 
File: program.cs 
Code Container: Class Demo 
Available Operations: d+ < 
        Kind                         Name 
        -------------               ----- 
d+ < vsCMElementProperty Enabled 
d+ < vsCMElementProperty Valid

#spacing added for readability
> ls -recurse | where { $_-match 'property' -and
   $_.access -match 'public' -and
   $_.type.asFullName -match 'bool' } |
foreach { $_.RenameSymbol( "Is"+$_.Name ) } 

> ls 
Location: dte:\solution\codemodel\demoapp\program... 
File: program.cs 
Code Container: Class Demo 
Available Operations: d+ < 
        Kind                         Name 
        --------------              ---- 
d+ < vsCMElementProperty IsEnabled 
d+ < vsCMElementProperty IsValid 
d+ < vsCMElementProperty IsRunning 
d+ < vsCMElementProperty Name 
d+ < vsCMElementProperty Applied

#spacing added for readability
> ls dte:/solution/codemodel -recurse | where { 
   $_-match 'property' -and
   $_.access -match 'public' -and
   $_.type.asFullName -match 'bool' 
} | foreach { $_.RenameSymbol( "Is"+$_.Name ) }

Done.  The total time it took me to complete the task across the 200+ files, including the necessary research, prototyping, and the full script execution: less than 30 minutes.  My input focus never moved from the StudioShell console, and my hands never left the keyboard (except when the script was running across the code base, during which time I helped my kids study their math facts).

This is why I made StudioShell – so I can scale iterative code and IDE solutions the same way an IT pro scales administrative solutions.  If a solution can be applied to a single line of your code, StudioShell can be apply it to all lines of your code.