Unfortunately all of these tools are restricted in one normally insignificant way: they only operate on the currently loaded project(s). For most software this really is insignificant. The entire application can be loaded into the IDE all at once. Sometimes, though, it is a problem–usually when there’s another problem at play: code "bloat" (via Jeff).

If you’ve ever changed a namespace and wanted to simply push the change into every code file in an entire directory branch, PowerShell comes to our rescue with it’s search-and-replace capabilities. I wrote the following "Move-Namespace" function to do just that.

Invoke the function like so: "Move-Namespace *.cs "[current namespace]" "[current class name]" "[new namespace]".

After it completes, any explicit reference will be changed, and any implicit references (using traditional "using [namespace];" statements) will have a new "using [new namespace];" line inserted after the last existing using statement.

Let’s hope you don’t have a code base that requires this function. But if you do, I hope it helps!

Note that this function relies on my "Replace-String" function, found here.

function Move-Namespace(
    $includes = $(throw 'Specify a file filter to use'),
    $oldNamespace = $(throw 'The namespace to replace - i.e. MyCompany.Product'),
    $className = $(throw 'The class name to search for - i.e. MyClass'),
    $newNamespace = $(throw 'The new namespace to add - i.e. MyCompany.Product.Feature'))
{
    # Look for cases of $className
    # or $oldNamespace.$className
    # and replace as necessary

    # First check for assumed "using" statements, and add the using statement
    $results = @{}
    $files = get-childitem -r -i $includes | select-string "(?<!$oldNamespace\.)\b$className\b" -list |% { $_.Path }
    select-string "^using.*;" -path $files | group-object Path | select-object Name, @{Expression={ ($_.Group | measure-object -property LineNumber -max).Maximum }; Name="LastUsingStatement" } |% { $results[$_.Name] = $_.LastUsingStatement }
    foreach ($key in $results.keys)
    {
      $processFile = $true
      $lastUsingIndex = $results[$key]
      $fileContents = get-content $key
      # look for existing using statement and cancel processing this file
      for ($i = 0; $i -lt $lastUsingIndex; $i++)
      {
        if ($fileContents[$i] -match "using $newNamespace;")
        {
          # this file already has the correct using statement, stop processing
          Write-Warning "File $key already has the required using statement, ignoring"
          $processFile = $false
          break;
        }
      }

      if ($processFile)
      {
        $newContents = $fileContents[0..($lastUsingIndex-1)] + "using $newNamespace;" + $fileContents[$lastUsingIndex..$fileContents.Length]
        set-content -path $key -value $newContents
        Write-Host "Successfully updated file $key" -foregroundcolor Green
      }
    }

    # Next check for explicit references
    replace-string "\b$oldNamespace\.$className\b" "$newNamespace.$className" $includes
}

I got some good feedback on the utility, along with some additional feature requests that ran outside the bounds of what the symstore utility offered. That lead me to upgrade my project to include a full-fledged (well, almost) symstore replacement, plus the GUI manager utility.

I’ve published the project tonight on CodePlex as "PSSymbolStore", and I’ve released the initial 0.1 beta release.

So what did I add and what did I change?

PowerShell

PSSymbolStore is now founded on a set of PowerShell cmdlets that replace and extend symstore’s functionality. (Almost: I need some feedback about a few symstore features and how they might work in the PowerShell world. If you’re a symstore wizard – ahem, John – drop me a line.) The initial release includes the following cmdlets, along with full help, including examples:

• Add-Symbols – Adds symbols to the symbol store
• Get-Transaction – Retrieves some or all of the transactions from a symbol store
• Remove-Transaction – Deletes transaction(s) from a symbol store
• Lock-Transaction – Locks transaction(s), preventing them from being deleted with the Remove-Transaction cmdlet
• Unlock-Transaction – Unlocks transaction(s), allowing them to be deleted with the Remove-Transaction cmdlet

Symbol Store Manager

The Symbol Store Manager (formerly "Symbol Server Transaction Manager") is basically the same from a UI perspective, but has been massively gutted. The internal changes (MVP pattern, PowerShell hosting, etc.) are all for the better as they fully enable unit testing, which is coming in a future release. I’m looking for feedback on the UI – what I can improve, etc. It’s really basic right now. I had started adding a search feature using ShuffleText’s Highlight fuzzy search library, but didn’t have time to finish it the way I wanted so I’ve pushed it out to a future release.

vNext

So what’s coming next? I’ve already mentioned unit tests and searching. I’m also kicking around some UI enhancements. Aside from those features, and finishing up some "paperwork" like installs, I don’t currently have a strong feature list. If you have ideas, please either post them as a comment here, or even better on the codeplex project site. For example: would this be more useful as an MMC snap-in instead of a standalone application?

Download PowerShell if you haven’t already, and give PSSymbolStore 0.1 Beta a whirl – I hope it’s useful!

But I think I’ve been very wrong. A while back Jeffrey Snover posted a great “core dump” of cmdlets vs. APIs. He makes some good points, but even after reading it (back when he first posted it) I still thought that API + Cmdlet was the best approach. Experience has changed my mind. Here are, in my opinion, the most important points from his list (paraphrased).

Error handling. An API can throw exceptions, but a Cmdlet can have terminating and non-terminating errors. With Cmdlets users can easily control the behavior when a non-terminating error occurs as well as get access to the collection of troublemaker objects.

-WhatIf, -Confirm, and -Verbose support. There simply isn’t an easy way to have an API support a -WhatIf type of operation, while remaining a good API.

Pipelines and wildcards. Wildcard support needs to be implemented on a per-API basis, making it a time-consuming (and possibly difficult) task. Working with “pipelines” requires specific coding by the user of the API.

The common thread between those three points is that an API simply can’t provide those services independent of Powershell. You really can’t create an API and wrap it in a Cmdlet. (If you have a choice.) If my “Remove-Foo” Cmdlet simply wraps “foo.Delete()”, “foo.Delete()” can’t make use of advanced error handling, or conditional processing (ala “-WhatIf” or “-Confirm”), or pipeline or wildcard support.

Because applications can host a Powershell runspace, any argument for an API goes away. Your Cmdlets are an API that developers can write code against. The thing that still gets me about this, though, is the verbose code it requires to exercise a Cmdlet’s “API”. Apparently Powershell V2 is going to help simplify the runspace hosting story. Maybe that’s enough to knock the final leg out of my leaning towards an API? Once I finish my work, perhaps I’ll update the symstore SnapIn for V2 – in the meantime, I’d like to release them in a state that people could actually use them.

I’m excited to download it and check it out – though as a non-admin I don’t do enough with PowerShell to be as excited about what seems to be the killer feature: Remoting.

function New-TableOfContents($path)
{
    # Verify the path exists and retrieve the official full path
    $root = (Get-Item $path).FullName

    Write-Output "<html><head><title>Table of Contents</title></head><body><h1>Table of Contents</h1>"
    # For each child item that's not a directory, create a link containing the relative path
    Get-ChildItem $root -recurse | where { $_.PSIsContainer -eq $false } |% {
        # Strip the root out of the path name (including the trailing slash)
        # in order to create a hyperlink that can be used from any location
        $relPath = $_.FullName.Remove(0, $root.Length + 1)
        # Write the link out - this is where you could get fancier with what you output
        # For example, you could include the last modified date/time, etc.
        Write-Output "<a href=`"$relPath`">$relPath</a><br />"
    }
    Write-Output "</body></html>"
}

This function will output the html to the pipeline, which doesn’t do us much good unless you direct it somewhere useful, like a file. While it’s tempting to make a function like this output the results to a file (replace “Write-Output” with “Out-File -append”), I’m of the opinion that functions should return their results to the pipeline whenever possible, allowing the user to decide what to do with it. In this case, it’s as simple as this:

PS:> New-TableOfContents "C:\\Doc Tree" | Out-File "C:\\Doc Tree\\index.html"

It’s simple, but effective. And because PowerShell passes objects around instead of strings, you can easily include more information in the hyperlink, or create a table instead of a list, or sort, or whatever. The sky’s the limit.

A support request came in this morning for a customer who had accidentally deleted the source for one of their data sources. (Background: our client software displays directories–sort of like detailed address books–that can be sourced from pretty much anywhere.) They remembered that our client app maintains an encrypted local cache of the data and wanted to know if there was any way they could use that to create a CSV file to re-import back to the original data source.

My first thought: PowerShell.

It took 20-30 minutes to review and remember what our application code was doing and create a PowerShell script that decrypted the data and exported it to CSV. It helps that we used standard .NET functionality like the built-in serialization of a DataSet and the Data Protection API. If anything had been customized it would’ve been trickier, but still do-able.

End result, here’s the script (it’s also available for download here, if you’re an Interactive Intelligence customer and find it useful in some way) — completely unsupported of course, use at your own risk, etc.

param
(
    [string] $i3DirFile = $(throw "You must specify an i3dir file that has been created on this same machine"),
    [string] $outputCSVFile = $(throw "You must specify an output file name for the resulting CSV data")
)

# Load the DPAPI assembly
[System.Reflection.Assembly]::LoadWithPartialName("System.Security") | out-null

# Load the encrypted file
$encryptedData = get-content -encoding byte $i3DirFile
$decryptedData = [System.Security.Cryptography.ProtectedData]::Unprotect($encryptedData, $null, [System.Security.Cryptography.DataProtectionScope]::LocalMachine)

$rawXml = [System.Text.Encoding]::UTF8.GetString($decryptedData)

$dataset = new-object System.Data.DataSet
$reader = new-object System.IO.StringReader($rawXml)
$dataset.ReadXml($reader, [System.Data.XmlReadMode]::ReadSchema) | out-null

$dataset.Tables[0] | export-csv $outputCSVFile

That’s it! Just 8 or so lines of code (with no error checking, of course). A great example of how PowerShell came to the rescue, even though this had nothing to do with the command line, or scripting, or PowerShell itself.

That’s been my spare-time-life on and off over the past few weeks, and now you all get to benefit from my pain. Here are the requirements I had to move to a new blogging platform:

1. Self hosted – while not a hard-and-fast requirement, I really want something I can tweak if necessary. And it can’t be ASP.NET-based, as much as I wanted it to, because I’m not going to pay for ASP.NET hosting. As a developer I also get warm fuzzies about being in 100% absolute control. (Okay, really, as a human being I get warm fuzzies about being in 100% absolute control…)
2. Old permalinks need to 301 redirect to new permalinks – I don’t have a lot of subscribers (but I love you all, so very much) and get a very modest number of hits every day. I really want/need those old links to point to the new ones. It needed to be seamless.
3. Full, or nearly-full, import – I wanted to bring as much information as possible from my Blogger blog to my new blog platform. That means no “import from RSS” features for me, I wanted comments to come over, etc.
4. Well used/tested, and feature rich – I wanted a blog engine that’s been proven. I don’t want to be overwhelmed with spam, or anything else. Along those lines, if a platform is going to be mature, it should have plenty of features. I want to be able to do things like moderate comments (if I ever feel like it), write an occasional article instead of a blog post, etc.

Given those requirements, I decided to switch to Wordpress, and here’s how I did it. (Spoiler: it took longer than I thought it would, required some custom development, and worked out okay in the end.)

I would divide my tasks into three components: exporting from Blogger, importing to Wordpress, and “general configuration” (permalink redirects, etc.)

Export from Blogger

I’ve actually already posted on this here. I decided on BlogML as my “offline” format for my blog, and wrote a PowerShell script to export from Blogger and output the BlogML format. So step one, export to BlogML using my script.

Figure 1. Exporting from Blogger to a local BlogML file.

Import to Wordpress

Update: Rob Walling from softwarebyrob.com has updated the import module to work with Wordpress 2.3 – get the updated version from my tools page. Thanks Rob!

This took the most work. The first thing I had to do was write a Wordpress import module for BlogML, since none existed. You can download the import module here. IMPORTANT NOTE: This requires the Php.XPath library available from SourceForge. Go there and download v3.5, making sure to upload it to the same directory as “blogml.php” (typically something like “/wp-admin/import/”). It is a single .php file. You’ll need to do this at least until I figure out how licensing works between BlogML and Php.XPath–once I get that figured out I’ll be adding this import module to the BlogML CodePlex project.

My steps were as follows:

1. Back up my Blogger files (on my FTP server) to my local hard drive.
2. Log into my Wordpress install and update the URL to be “http://www.aaronlerch.com/blog” (instead of the intermediate location of “http://www.aaronlerch.com/wp”). Note that as soon as I saved this setting, it tried to redirect me to a location that doesn’t exist yet. It’ll fail, that’s okay.
3. Rename the “/blog” directory with my Blogger files to something else, and rename my intermediate Wordpress directory “/wp” to “/blog”.
4. Change the encoding in my BlogML output file. This sucks, but the XML class I used (Php.XPath) requires the XML to be in UTF-8 format. My Blogger->BlogML export script generates it using the .NET APIs, which uses UTF-16 (Unicode) encoding by default. Instead of spending a lot of time tweaking the BlogML output-which wouldn’t benefit anybody but myself-I just fired up Notepad2 and changed the file encoding to UTF-8 (File -> Encoding -> UTF-8), making sure to also update the “encoding” attribute of the “<?xml” header tag from “utf-16″ to “utf-8″.
   
   Figure 1. Be sure to change the “encoding” attribute of your XML file when changing the file encoding.
   
   Figure 2. Before conversion – “Unicode BOM” (BOM = Byte Order Mark)
   
   Figure 3. After conversion – “UTF-8″
5. Import my BlogML export from Blogger into Wordpress (very straightforward–just try it). On the “completed” page of the import, it lists the posts that were imported, and at the bottom it gives a link to a permalinkmap.csv file which contains a mapping of old permalinks to new permalinks. I downloaded that file and saved it for use later.

General Configuration

Finally, I needed to set up my redirects. Using the permalinkmap.csv file I downloaded, I ran the following PowerShell one-liner to create a text file containing entries that I copied into my “.htaccess” file (my hosting company uses LAMP):

import-csv permalinkmap.csv |% { $oldurl = ($_.OldPermalink -replace “http://www.aaronlerch.com”, “”); “redirect 301 $oldurl ” + $_.NewPermalink } | out-file htaccessredirectdata.txt

It simply creates a list of redirect commands that end up looking something like this:
redirect 301 /blog/2007/08/uri.html http://www.aaronlerch.com/blog/2007/08/21/uri-purity/

Finally, I needed to set up redirects for my archive files. Those were all stored in a single “archive” subfolder by Blogger, which I had locally as part of my original backup. This PowerShell one-liner output more redirect commands for me to copy into my .htaccess file:

dir archive | select Name |% { ($_ -match “([0-9]{4})_([0-9]{2})_.*”) | out-null; “redirect 301 /blog/archive/” + $_.Name + ” http://www.aaronlerch.com/blog/” + $matches[1] + “/” + $matches[2] + “/” } | out-file archivehtaccessdata.txt

This short command takes a file named “2007_08_01_archive.html” and produces the following redirect line:
redirect 301 /blog/archive/2007_08_01_archive.html http://www.aaronlerch.com/blog/2007/08/

Cleanup

What good blog migration would be complete with out some cleanup? The export/import process mangled some special characters various blog writing tools I’ve used inserted. Not to mention code examples getting new-lines removed. (Beware!) A quick visual skim and it was all fixed up.

Conclusion

So what do we take away from all this? A few things:

• Cleanly migrating between blogging platforms sucks. It’s not straightforward, and “clean” is in the eye of the beholder.
• If you ever want to migrate from Blogger to Wordpress, you’ve hopefully found some help here. At a higher (even more helpful) level, if you ever want to export from Blogger to BlogML, or import from BlogML to Wordpress, you’ve got some tools and guidance.

Technorati Tags: blogml, blogger, wordpress, powershell

I presented on Windows PowerShell last night at Indianapolis .NET Developers Association meeting. Considering it was my first-ever presentation to a group anywhere close to that size (technical or otherwise), I thought it went very well. Feedback was good, including some constructive criticism, which I wholeheartedly agreed with. Considering my audience (developers who likely don’t live on the command line like my co-workers and I tend to–which isn’t a bad thing) I unintentionally spent too much time covering using the command-line and not enough time doing the demos on writing cmdlets or hosting powershell in apps, etc. Live and learn, I always say! The biggest lesson I learned? Going barefoot while presenting is a Good Thing^TM. It made me feel so much more at ease. Ahhh, bare feet.

If you were there, or are just interested, you can download my illustrious PointPoint presentation and demo code. Note that I’m not a huge fan of a lot of PowerPoint slides in technical presentations, so you’ll see that I really only have 2 content slides (and use of the word “content” is questionable).

Presentation (Office 2007 format)
Presentation (Office 200x format)
Demo code/scripts

Due to the really short time I had to prepare, I’d like to say a huge thanks to Jeffrey Snover for his Start-Demo script (and some example demos using it), David Aiken for his “DFO Show” walk-throughs (and associated code), Lee Holmes for his “MSH Logo” app, and Scott Hanselman for some presentation advice (including responding to some extra questions I had). I totally hijacked their stuff, but did give full credit for it.
Note that I’m including my “tweaked” versions of their applications here, for all to enjoy. But all credit goes to them for originally creating it–I hardly did anything to it, literally. You guys all saved me, thanks!

Due to the very short notice (I just found out a day or two ago) I’ll mostly be aggregating existing demos from the web and doing them live, as well as walking through using PowerShell much like Scott Hanselman did for his user group presentation.

It should be a good time – hope to see you there.

My frustration led me to create a PowerShell script to export a Blogger blog to BlogML. Other methods exist, but they all required changing something about my blog, whether it was the template, or the hosting (and thus domain name). Not gonna happen. The script makes use of the BlogML .NET library (for ease) and the Blogger API. No Blogger login is required, you simply have to specify your “userid”. Your user id (it’s most likely public) can be found in your profile URL, like so:

Once you get that id, just run the script and pipe the output to a file. The output is actually an array of strings, each one is BlogML XML that represents a single blog. You can have multiple Blogger blogs associated with your user account–this will automatically download all of them. You can change the script not to do that if you need to.

To use it, type the following at the command line, I’m using my user id as an example (and I know I only have a single blog):
PS C:\Test> .\BloggerToBlogML.ps1 “17257708406345880368″ | out-file aaronlerch.blogml.xml

You’ll get a progress bar as it downloads your posts, and when it’s completed it shows a short summary.

Download the script here, or from my Garage Sale Code page. Let me know of any bugs or improvements I can make–I made it do what I needed, and not much more (the Blogger API is a little sparse anyway), but I’m happy to update it to include more if someone has a need.

Technorati Tags: powershell, blogml