Wednesday, October 03, 2007

Holy poop! This is huge!

I know Scott was leading the charge in a general source code cleanup which started some times ago, but it looks like they're nearly done! This is amazing - from within VS 2008 (or your favourite source code editor), you'll be able to seemlessly single-step debug from your own code in that of the .NET framework itself.

Bravo Microsoft! This is an incredibly symbolic step!

http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx

posted on Wednesday, October 03, 2007 4:02:52 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
 Saturday, September 22, 2007

Marco Shaw recently asked on the powershell newsgroup:

Anyone have a working example of using "CodeMethod" to define methods
for a custom object?

And funnily enough, not even Microsoft themselves seem to have a decent working example. So, spelunking in the packaged Types.ps1xml that comes with a PowerShell install I found only three examples. Let's look at the ETS definition for one of them (XmlNode.ToString) in Types.ps1xml:

<Type>
  <
Name>System.Xml.XmlNode</Name>
    <
Members>
      <
CodeMethod>
        <
Name>ToString</Name>
        <
CodeReference>
          <
TypeName>Microsoft.PowerShell.ToStringCodeMethods</TypeName>
          <
MethodName>XmlNode</MethodName>
        </
CodeReference>
      </
CodeMethod>
   </
Members>
</
Type>

Using Reflector, I took a look at the managed code providing this service - btw, ETS CodeMethods are always provisioned by static methods on a managed type:

public static class ToStringCodeMethods
{
    ...
    public static string XmlNode(PSObject instance);
    ...
}


The C# 3.0 users among you will see a remarkable similarity to Extension Methods here, except here ETS CodeMethods can also replace a native method if you so desire. To define a new CodeMethod, you need to provide the full type name, the name of the static method and the ETS method name for the extension method on the target type. In this particular example, all instances of XmlNode exposed in PowerShell will now have their native ToString method replaced with this new one. When you invoke ToString on the XmlNode instance, the static method ToStringCodeMethods.XmlNode will be invoked and the instance parameter will be passed the PSObject wrapped XmlNode. Taking the only three examples in Types.ps1xml at face value, one might assume that CodeMethods can only be parameterless, but it appears not to be the case...

ETS Code Methods with additional parameters

A little experimentation verified that to me that we're not stuck with parameterless codemethods; any additional parameters you define on your static method will be bound to parameters provided in a script invocation of the ETS CodeMethod. The first argument is mandatory for any statics providing CodeMethod services: it will always be passed the ETS extended instance. Here are three examples of some multi-argument signatures and the backing managed code to provide ETS with the implementation:

<Types>
 <
Type>
  <
Name>System.String</Name>
  <
Members>
  <
CodeMethod>
   <
Name>Test1</Name>
   <
CodeReference>
    <
TypeName>Nivot.CodeMethods.TestCodeMethods</TypeName>
    <
MethodName>TestNoArguments</MethodName>
   </
CodeReference>
  </
CodeMethod>
  <
CodeMethod>
   <
Name>Test2</Name>
   <
CodeReference>
    <
TypeName>Nivot.CodeMethods.TestCodeMethods</TypeName>
    <
MethodName>TestOneArgument</MethodName>
   </
CodeReference>
  </
CodeMethod>
  <
CodeMethod>
   <
Name>Test3</Name>
   <
CodeReference>
    <
TypeName>Nivot.CodeMethods.TestCodeMethods</TypeName>
    <
MethodName>TestVariableArguments</MethodName>
   </
CodeReference>
  </
CodeMethod>
 </
Members>
 </
Type>
</
Types>

And here is the corresponding backing managed code signatures:

public static class TestCodeMethods
{
    // Methods
    public static string TestNoArguments(PSObject instance) { ... }
    public static string TestOneArgument(PSObject instance, PSObject arg1) { ... }
    public static string TestVariableArguments(PSObject instance, params PSObject[] args) { ... }
}
Have fun!

posted on Saturday, September 22, 2007 3:42:05 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
 Friday, August 24, 2007

While I absolutely love MoW's PowerTab, there's been one little niggling thing that's been missing since day one; while you can navigate Types using the opening square bracket syntax, e.g. [<tab> , when using the new-object command this method is not totally syntactically compatible. (update: MoW explains in a comment below that there is a special trick for navigating without the square brackets, oops! me wrong!) You have to navigate to your type, then edit out the square brackets which is a little bit annoying. Also, when using this syntax you typically know exactly which type you need but can't remember the namespace. Or perhaps you know the type name, but don't want to have to type it all out (or navigate there).

So, I figured I'd crack open PowerTab and see how easy it was to implement. To cut a long story short, in about 30 minutes it was done. The thing that made it so easy was that MoW already has a DataSet in memory of all types and their namespaces, so the grunt work is done by a simple DataTable.Select call. I modified the function TabExpansion in TabExpansion.ps1 (version 0.96 b12), and put the following snippet just after the switch on $lastWord :

switch -regex ($lastWord) {

    # Handle inline type search, e.g. new-object .identityreference<tab> or .identityre<tab>
    '^\.(\w+)$' {
       
$typeName = $matches[1]
      
$types = $dsTabexpansion.tables["Types"]
       
$rowFilter = "name like '%.${typeName}%'"
       $types.select($rowFilter) | % {$_["name"] } | Invoke-TabItemSelector $lastWord -Select $SelectionHandler
       break;
    }

The type search is initiated by prefixing the full or partial type name with a period (.) and then hitting tab. There you have it, inline type search. Have fun!

posted on Friday, August 24, 2007 2:28:45 PM (Eastern Standard Time, UTC-05:00)  #    Comments [2] Trackback
 Monday, August 20, 2007

Another answer I posted to the NG, and not all that hard once you know the right classes to use from the BCL. But if you didn't know where to look, I can imagine it being a royal pain in the ass.

--- begin ConvertTo-Sid.ps1 ---

param ($account = $(throw "need account in form domain\username or
[ntaccount] object"))

if ($account -is [security.principal.ntaccount]) { 
    $ntaccount = $account

} else {
   
$ntaccount = new-object security.principal.ntaccount $account
}

$ntaccount.translate( [security.principal.securityidentifier] )
-- end ConvertTo-Sid.ps1 ---

and the reverse:

--- begin ConvertTo-NTAccount.ps1 ---

param ($sid = $(throw "need sid string or [securityidentifier] object"))

if ($sid -is [security.principal.securityidentifier]) {
    $securityidentifier  = $sid

} else { 
    $securityidentifier  = new-object security.principal.securityidentifier $sid
}

$securityidentifier.translate( [security.principal.ntaccount] )

--- end ConvertTo-NTAccount.ps1 ---

You can pass strings as args, or their respective native objects. They both output objects. The output of one can be used as the input of the other.

 

posted on Monday, August 20, 2007 4:50:36 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
 Thursday, August 16, 2007

Then get ready for PS+ !

http://www.powershell.com/plus/

 

posted on Thursday, August 16, 2007 3:32:09 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
 Tuesday, August 14, 2007

I got tired of typing add-pssnapin blah, especially with Quest's AD snap-in's longer than usual name so I came up with a little script that enumerates registered snap-ins, and lists a simple numbered menu showing those that are not already loaded into memory. You just type the number and hit enter to load it. Enter on an empty line exits the script. Yeah, it's brain-dead, but hey, I think I was brain-dead to continually type long commands in every single session to load stuff ;-) 

UPDATE 2007-08-16: I was even more braindead than I realised - I copied up a broken version without the $notloaded array. Ooops. Fixed.

  1. write-progress "Enumerating Snapins" "Registered..."
  2. $snaps = get-pssnapin -r
  3.  
  4. write-progress "Enumerating Snapins" "Loaded..."
  5. $loaded = get-pssnapin | % {$_.name}
  6. $notloaded  = @()
  7.  
  8. write-progress "Enumerating Snapins" "Complete." -Completed # glitchy
  9.  
  10. $i = 0; "";
  11.  
  12. foreach ($snap in $snaps) {
  13.         if (-not($loaded -contains $snap.name)) {
  14.                 Write-Host -fore cyan -nonewline "${i}) "
  15.                 write-host -fore green $snap.name
  16.                     $notloaded  += $snap
  17.                 $i++
  18.         }
  19. }
  20.  
  21. if ($i -eq 0) {
  22.         Write-Warning "Any eligible snapins are already loaded."
  23.         exit;
  24. }
  25.  
  26. $i--;
  27. Write-Host -fore yellow "<enter> to quit"
  28.  
  29. do {
  30.         write-host -nonewline "Load 0 - ${i}: ";
  31.         $choice = [console]::readline()
  32.         if ($choice -and ($choice -lt 0) -or ($choice -gt $i)) {
  33.                 Write-Warning "'${choice}' is out of range!"
  34.                 continue;
  35.         }
  36.         if ($choice) {
  37.                 "loading $($notloaded[$choice].name) ..."
  38.                 add-pssnapin $notloaded[$choice]
  39.         }
  40. } while ($choice)


Just pop it into a function or a ps1 script.

You'll notice how when this is run from a clear screen, the progress bar disappears, then suddenly reappears and the first few menu items are hidden. This is a bug in the powershell.exe host. Vote on it here:

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=291380&SiteID=99

 

posted on Tuesday, August 14, 2007 3:05:06 PM (Eastern Standard Time, UTC-05:00)  #    Comments [2] Trackback