LL01 – “Bend” the tools to your need

Preface: For 2013, I’m planning to write more, and focus my attention on the Lessons Learned (LL) that come from 10 years of experience in software development. It should be more about a general attitude towards productivity rather than specific solutions. These posts will be easy to spot, as they will have a “LLxx” prefix. Hope you enjoy reading them🙂

Ok, now on to the post…

Today I was faced with a challenge: something was not working with a Web project I was upgrading, and as sometimes happens, the error messages were not helpful at all. Trying to get to the bottom of this, it was time to fire up Fiddler and check the errors during the initialization (I was mostly interested in the 404s :)).

The thing is, for some reason Fiddler just wasn’t working with IIS Express 7.5. There are a lot of tricks available, some I knew from using it with Cassini (Web Dev Web Server) and others I found while Googling for a solution. But none of them worked, I was still unable to see the HTTP traffic.

I could go on and on trying to get Fiddler and IIS Express to work together. And, as developers are wont to do, trying to get all these tools to function perfectly in the development machine. However, let’s not forget the main pirority: the Web project must work again, the deadlines must be met and there are other people waiting for it.

The solution was found quickly and it was so, so simple… I already had an IIS virtual directory for the same module, which was installed by the product setup. It was simply a matter of redirecting the virtual directory path to the development output folder, and then fix, build, fix, build and so on… Fiddler was intercepting the HTTP requests/responses perfectly.

So, there it is: Lesson Learned #1 – What matters is the task at hand, not the tools in use. And if they fail to cooperate, there’s nothing wrong with “bending” them a little and make them work to your advantage.


I found this site while searching for a way to remove duplicate lines, and it works like a charm. They have a few other useful tools as well.

I wouldn’t say they have “all the text tools you need”, however coupled with a regular expression tool such as Expresso (which I highly recommend), you can hack away at a bunch of text and get the results you want.


TextOpus – http://textop.us/

Expresso – http://www.ultrapico.com/Expresso.htm

Roslyn Sample: Rename items in a solution

Sometimes you make mistakes. No really, you do. Sometimes you use an incorrect term or word in a project, and then you need to replace it everywhere.

While it is quite easy to do this within source files (with a simple search/replace or building a tool to do it in bulk), it’s not so easy to rename the source files. Worst even if they are checked-in to source control.

After getting to know the Microsoft “Roslyn” CTP, it seemed like the right tool to help with this task. I needed to rename a lot of files in a solution to match the new class names. I had already built a small sample that went through a solution/projects/documents and created a text report.

It was only a matter of adapting this sample with a few tweaks. As always, the effort put into automating something should be worth it. So I followed the ASAP principle, which in this case means As Simple As Possible.

Instead of fiddling with the TFS API, the idea was to keep the “project iterator” and output a command-line instruction into a file whenever a document name matches the search criteria. After generating the file, its contents can be checked against the expected result, and if everything is OK, running it will rename all the files.



using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using Roslyn.Services;
using Roslyn.Scripting.CSharp;

namespace RoslynSample
  class Program
    static void Main(string[] args)
      RefactorSolution(@"C:\Src\MyApp.Full.sln", "ExternalClient", "ExternalCustomer");


    private static void RefactorSolution(string solutionPath, string fileNameFilter, string replacement)
      var builder = new StringBuilder();
      var workspace = Workspace.LoadSolution(solutionPath);

      var solution = workspace.CurrentSolution;

      if (solution != null)
        foreach (var project in solution.Projects)
          var documentsToProcess = project.Documents.Where(d => d.DisplayName.Contains(fileNameFilter));

          foreach (var document in documentsToProcess)
            var targetItemSpec = Path.Combine(
            document.DisplayName.Replace(fileNameFilter, replacement));

            builder.AppendFormat(@"tf.exe rename ""{0}"" ""{1}""{2}", document.Id.FileName, targetItemSpec, Environment.NewLine);

      File.WriteAllText("rename.cmd", builder.ToString());

Microsoft “Roslyn” CTP

The Microsoft “Roslyn” is an effort to open the compiler and language services “black boxes”, and enable developers to create powerful code refactoring, analysis and interpretation tools.

The CTP was released late last year, and so far it seems very promising. Let’s see what this thing can do…




Visual Studio Favorites

When projects grow, sometimes they really grow. And then you find yourself endlessly scrolling up and down, expanding and collapsing project nodes, trying to find that element you really need. This is true for Visual Studio solutions, as well as for Team Projects.

There is a common solution for this in many instances, which is called Favorites. There should already be something similar available for VS, so I went searching and this is what I found.

There is a built-in solution for Team Explorer, which already supports Favorites (see here and here). For Visual Studio solutions and projects, there is an extension that lets you create favorites pointing directly to files or jumping to their location within the Solution Explorer.

The Solution Navigator solved the issue of quickly finding a file within a project, however using favorites has two distinct advantages: it’s faster and you can open the file directly in the editor with a single click.





AutoHotkey (and more…) @Lifehacker

I’m very glad to see that I’m not the only one praising the many virtues of AutoHotkey. The guys at Lifehacker have a couple of tutorials on how to set it up for hotkeys, and combining it with NirCmd. I’ll have to take a look at NirCmd to see if there is anything interesting that can be done with it… But that’ll be a topic for another post.




PS: Follow Lifehacker on Facebook or via RSS, they publish fantastic tips and tricks, and not only about technology.

AutoHotKey Form Filler

I’ve previously introduced AutoHotKey (here and here) as a powerful UI automation tool. Recently I’ve been using a installer interface (a kind of initializer) for an application we’ve developed, and finding myself inputting the same values over and over again.

AutoHotKey was a likely candidate for automating this task. However, the UI was built using WPF and there was no way of finding the controls where the values had to be changed! Thinking about the issue, it’s actually only a matter of sending a few keystrokes. So I developed a simple script that sends the necessary keystrokes to fill the form:

IfWinExist, MyInstaller
WinActivate, MyInstaller

; SQL Server
Send, ^a

; Authentication Mode
Send, {Tab}
Send, {Down}

; SQL Server Login
Send, {Tab}
Send, ^a
Send, MyUser

; SQL Server Password
Send, {Tab}
Send, ^a
Send, MyPassword

; Database Name

Send {Tab 4}
Send, ^a
Send, TheDatabase

; Set Overwrite = YES

Send {Tab}
Send {Up}
MsgBox, Installer window not found!

Many times simple is better, and it doesn’t get simpler that this. It just requires that the first textbox is focused before running the script. The script only took 5 or 10 minutes to create.

One can argue that filling such a form only takes a few seconds, and that the time savings are negligible. There is always a huge advantage in automating, and it is not about time: it is about quality. Using this script ensures that no typing errors are made, so the correct database is selected and created. I only have to verify that everything is OK and click Next.