At this stage of cloud maturity for productivity, most of us will have all of our documents, emails and contacts stored in one kind of cloud service or another. As I try to migrate from the loan PC to the permanent PC I notice I’ve been my usual sloppy self, and there are plenty of documents on the Desktop, and in the My Documents folder. Those are easy enough to clean up, but then I come to my C:\code folder and realise there are a number of things in there that are about to be lost. 

It’s not that using source control is particularly hard, but it’s a discipline that needs to be practiced not only to protect assets worked on, but in my role to create a repository where I can easily share what I’ve been talking about with people I work with.

For a number of reasons, but mostly familiarity, I’m going to use GitHub. Creating a repository is incredibly simple, which means I’m up and running almost immediately. And as per above, I’m going to be making my repository public so that I can share what I’m working on with anyone who’s interested. Naturally the other key benefit is people can contribute as well.

Very important is to consider the license being used. For this repository which is going to store the code from my last post, I’m using the MIT license. MIT allows reuse of my code in most other licenses including GPL. There’s nothing secret in what the code does, and it can only be beneficial as an enabler to people who want to accelerate the setup of Open Live Writer, so an MIT license makes perfect sense. It’s something that does need to be understood though – there are many types of license available and the appropriate one for each type of code or project should be carefully considered.

After clicking Create Repository, I have my empty repository ready to be used.

Now I need to add my file(s). For what I have here, it’s really simple to just add them using the upload files button.

and now it’s available and safely in source control for the next time I need it.

It’s a really basic thing to do, and something that’s well understood and managed in a software developer’s day, but something I often forget until it’s too late. I’ll be trying to make this a good habit to form.

One of the things I’ve been keen to do is make sure I have a way to format my PowerShell scripts, as it’s my preferred way of automating what I do in Azure.

Open Live Writer doesn’t yet have plugin support, but searching around I found a plugin written by a developer named Richard Hewlett. It needs to be manually updated, and thanks to numerous PC changes I seem to have been through the process three or four times now without ever getting a blog posted. After continually referring to Benjamin Perkins’ steps to make this work, I’ve decided in the spirit of what I’m trying to achieve I should write a script that will automate the process.

First step is to download the file. It’s coming directly from the download area of Rich’s blog, so I’ve hard-coded the URL in. It’s at the top, so easy enough to change if/when the file is updated. The file comes down to the directory the script is run from, so the assumption is the credential it runs under has permission to write there.

Next up the destination directory for the plugins is created under the application folder. To attempt to future-proof the script I haven’t added the application version number, I’ve set it to iterate through folders that have “app-“ as the prefix. It’s not foolproof, but might keep the script working if the app team doesn’t change the folder structure.

The downloaded .zip file is then decompressed to the newly created plugin directory, which is made simple with the Expand-Archive cmdlet.

Finally there’s an xml file that needs a new element added. OpenLiveWriter.exe.config is in the main application directory, and needs the element loadFromRemoteSources added to runtime.

Put together, here’s the script, and it was used to setup Open Live Writer on my new machine to write this post!

#download zip file for syntax highlighting
$url = "https://richhewlett.blob.core.windows.net/blogdownloads/SyntaxHighlight_WordPressCom_OLWPlugIn_V2.0.0.zip" 
$path = (Get-Item -Path ".\" -Verbose).FullName + "\SyntaxHighlight_WordPressCom_OLWPlugIn_V2.0.0.zip"

Write-Host "Downloading [$url]`nSaving at [$path]" 
$client = new-object System.Net.WebClient 
$client.DownloadFile($url, $path ) 
      
#create destination directory
$LocalAppDir = [Environment]::GetFolderPath("LocalApplicationData")
$OpenliveWriterDir = $LocalAppDir + "\OpenLiveWriter"

#just in case there are multiple versions installed, or there's an upgrade, enumerate the application binary folders
$appDirectories = Get-ChildItem $OpenliveWriterDir | Where-Object {$_ -like "app-*"};

foreach ($appDirectory in $appDirectories) {

    #Create destination directory
    $targetDir = $appDirectory.FullName + "\Plugins"
    if(!(Test-Path -Path $targetDir )){
        Write-Host "Creating path $targetDir"
        New-Item -ItemType directory -Path $targetDir
    }


    #decompress file into target directory
    Write-Host "Expanding $path to $targetDir"
    Expand-Archive $path -DestinationPath $targetDir

    #update config file
    $configFileName = $appDirectory.FullName + "\OpenLiveWriter.exe.config"
    [xml] $xml = gc $configFileName

    #create the new element
    $newitem = $xml.CreateElement("loadFromRemoteSources")
    $newitem.SetAttribute("enabled","true")

    #if it doesn't already exist in the file, add it and save
    if (!$xml.SelectSingleNode("//loadFromRemoteSources")) {
        $xml.DocumentElement.LastChild.AppendChild($newitem)
        $xml.Save($configFileName)
    }    
}

Blog posting done, and my next imminent rebuild streamlined. At least a little.