Most of the work I currently do (during the day) is with WinForms applications and most of the time, debugging their problems really isn't all that hard. Application hangs or crashes that only occur on one machine at a remote location are not easy though. We ran into one of those situations a few weeks back. I told our support group that if they saw the hang again to let me know and I would swing by so that we could get a memory dump of the application and start debugging it. Here's everything I did to figure out what went wrong.

First thing, install Debugging Tools for Windows. This will get you things like adplus and windbg. Make sure you pick the right version for your platform (i.e. x86 or x64) because the debugger has to match the platform you're debugging on. I already had it installed on my machine, but I shared the directory so that I could access the tools on the remote machine that was having the hang.

Next, I remoted into the machine with the problem and ran adplus to get a memory dump. To do this, I first copied over the debugging directory to the remote machine from my share. Luckily, the Debugging Tools can be copied and therefore don't need an MSI or setup executable. To get the dump, I pulled up a command prompt, moved to the debugging directory, and ran 'adplus -hang -p 3423' where 3423 was the process ID for the application that was hanging. If you're dealing with an application that is crashing, you would need to pass different arguments in. By the way, note that adplus is just a VBScript - this means that you can open it and see what they're doing if you're so inclined. You can get the PID from either task manager or process explorer.

Let this script run to completion and it should create the memory dump (in this case, a minidump) in a directory that looks something like this:

I then zipped up this directory and copied it back over to my machine so that the user could get back to work Get back to your desk because you'll be able to do everything else there.

This is where it gets fun, because we get to use WinDbg. Before doing any real work with WinDbg, I would strongly recommend getting your colors customized because it is very hard to spot errors or warnings when all the text is black on white. Check out Tess's post on setting up a custom workspace for WinDbg. I set up WinDbg exactly as she did in the post and it works quite well.

Next, you can open your minidump. Under the File menu, there is an "Open Crash Dump" command that you can use (Ctrl+D for you keyboard guys) so pull that up and open your minidump file. It should look something like this:

You can think of WinDbg sort of like a command prompt, even though it has windows and buttons. It is just as user friendly as the command prompt is when you're sitting at the C: prompt. In other words, it isn't friendly at all. In this case, instead of a C: prompt, you have the prompt at the bottom of the screen.

WinDbg starts out as an unmanaged/native debugger, which means you could debug your managed application, but it will be fairly difficult with just native commands. What you need to use is a tool called SOS. John Robbin's, master debugging guru guy, has an excellent MSDN Magazine article on SOS that you should read for more information. My next step was to load up the SOS extension in WinDbg by typing '.loadby sos mscorwks' which tells WinDbg to load the SOS extension from the same directory as the mscorwks assembly was loaded from. (check out this comment for cases when the loadby might not work, such as when mscorwks hasn't been loaded yet)

When I typed it in, I unfortunately got an error, though (pasted below for Googlibility, if that's a word).

PDB symbol for mscorwks.dll not loaded
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of mscorwks.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine. 
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry. 
If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well. 

This got me digging for a while to figure out why I couldn't load up SOS. Quite a few other people were curious, too. The gist of it can be summed up in this Microsoft Connect post, which details that you have to have the exact same version of the .NET Framework as the machine where the minidump was taken. In short, I had installed .NET 3.5 on my machine which included patches to .NET 2.0 while the user who was having the problem was a few versions back.

To confirm this, you can use the loaded modules command (lm) to see all of the modules that were loaded at the time of the minidump. I specifically used 'lmv m mscorwks'. The 'v' apparently means details or something and the 'm mscorwks' tells the command to match on modules named 'mscorwks'. Here is the result, with the file version info from my local mscorwks file as well (found in c:\windows\microsoft.net\framework\v2.0.50727).

Don't despair if you're in this situation, because I have a solution. Virtual machines! It takes a bit of work, but you can get a VM set up with the same framework version. I started out with blank Windows XP SP2 VM and installed the .NET Framework 2.0 RTM on it. Turns out, I was still off. The below screenshot is from the VM.

I was starting to get frustrated at this point, but Doug Stewart saved the day with a couple of posts on .NET 2.0 versions, one on .NET 2.0 revisions and one on the version history of the CLR 2.0. I was able to determine that the problem computer was running a patch from KB928365. I installed the patch on the VM and... SUCCESS! SOS loaded up!

With SOS loaded, you run a lot more interesting and powerful commands from WinDbg, like !threads, !CLRStack, !analyze and more. Here are the basic steps I took to attempt to narrow down what was going on.

I ran !threads, which displayed all of the threads that were running at the time the minidump was taken.

You can see that, though it looks like a lot was going on, there really was the main STA thread (the thread that contains the WndProc which pumps the Windows messages) and a lot of system threads like the Finalizer threads and Completion Port threads.

You can switch between threads, by using the ~[THREAD]s command, like ~11s, which switches to the thread with the ID of 11. Once switched to a thread, you can run !clrstack and get the call stack for that thread.

It looks like thread 11 was an animation timer. Back on the main thread (STA), it really just looks like normal WndProc activity - nothing too strange.

It was looking like I wasn't getting anywhere, so I decided to try something else. I ran the DumpStackObjects (!dso) command, which gives me all of the object instances on the stack.

Looks like the application in question was using an Infragistics library, but the thing I was really interested in was the bottom one, the WinFormsAppContext, which was an instance of an ApplicationContext. From that instance, I could run the !do (dump object) command to see details about it.

From there, I wanted to find which mainForm it was using. I ran !do on the Value column of the mainForm instance.

Nice! Now I know the name of the instance that was loaded! At this point, I've got a much better idea about what is going on and can now start digging through some code to try to determine what it is doing.

The rest of the story is fairly boring because, after opening the offending code, I spotted the problem fairly quickly. The hang, if you even want to call it that, had nothing to do with threading. It just looked like the application was hanging because, in the Form's Closing event, the application in question was cancelling the close and hiding itself. I have no idea why, but I guess that's debugging for you.

To finish off, I'd like to share some excellent debugging resources, particularly with WinDbg.

• Anything from Tess's blog. Period.
• John Robbin's blog
• John Robbin's Debugging Microsoft .NET 2.0 Applications - awesome book on debugging.
• Johan Straarup has a great post on getting started with WinDbg.
• David Douglass's WinDbg / SOS Cheat Sheet

Hope this helps!

Here is a simple script I wrote which was inspired by this post on terminal color highlighting and by ColorDiff that does essentially the same thing.

# Out-ColorDiff.ps1
Process {
    if ($_) {
        foreach ($line in $_) {
            if ($line -match '^[<|-]') {
                Write-Host -ForegroundColor red $line
            }
            elseif ($line -match '^[>|+]') {
                Write-Host -ForegroundColor green $line
            }
            else {
                Write-Host $line
            }
        }
    }
} 

Here is a screenshot of sample output from the script:

You can use it by piping the diff output to the script, like 'svn diff somefile | out-colordiff' or if you're stuck using something like MKS, you can use 'si diff somefile | out-colordiff'.

Possible (and easy) additions would be to add direct parsing of a file instead of taking an argument off of the pipeline. This is all I need currently, but if you wish to add more features, feel free to leave them in the comments.

If you've been working with the .NET Framework for a while, you're hopefully already using some form of static analysis to help you catch problems with your code. One of the most well known is Microsoft's FxCop, which is now integrated as the Code Analysis feature in Visual Studio 2005 ^[1] and up. If you're not already using this tool, then please start because it can help you find problem areas like potential NullReferenceExceptions as well as globalization and security issues.

However, while FxCop is great at catching small problems and details, it isn't the best tool to see the big picture regarding your software. Enter NDepend by Patrick Smacchia. Chances are, you've already read Scott Hanselman's great review of NDepend a while back (or heard his podcast on static analysis with NDepend). If you haven't read it, go ahead and check it out. Scott uses NDepend to analyze dasBlog (which I'm running), so you can get the general feel for working with NDepend and what the reports look like.

I'd like to run through a few of the features of NDepend using Rhino Mocks as the target of my static analysis. Rhino Mocks is a neat example because it is only one assembly, but it is the result of an ILMerge of quite a few different libraries, so we get to see how NDepend handles this. Here is NDepend's class browser showing Rhino Mocks:

As you can see, it handles Rhino Mocks accurately. In fact, it almost feels like the class browser in Reflector, so that is already a plus. In fact, as you can see, the context menu supports jumping to Reflector for the selected type.

The "Who is directly using me?" option is also pretty cool and highlights the extensive use of CQL in NDepend:

CQL, or Code Query Language, is the centerpiece of NDepend and is how all of the analysis happens. You can think of it as SQL against IL. The massive benefit that NDepend has over FxCop IMHO is that you can create your own analysis rules in CQL instead of having to write and compile a DLL to extend FxCop (for an example of this, check out this FxCop rule that ensures that ArrayLists are List<T>s instead). Even better, NDepend provides a complete editor with intellisense that allows you to test your queries out against your assemblies.

Take a look at this screenshot. You can see the intellisense at the bottom right hand of the screen. At the top left is the CQL Query Results. The top right is all of the types in the assemblies, but the highlighted ones in blue are those that were returned by the query. This all happened as I typed the query in. Actually, I got red when I typed it in the first time, because my query had some mistakes in it, but NDepend was very helpful in showing me how to correct my query.

The query editor also has different types of intellisense depending on the value.

I'll admit that it might seem weird to have a slider when you're just typing a number in, but the cool part is when you change the value, the query results automatically change to reflect the new value. In this case, you can watch the results of the query to get a feel for which types have the most methods.

From an agile coding perspective, NDepend ties in well with Continuous Integration. It ships with both a NANT and an MSBuild task to run the NDepend console against an NDepend project file (which is just XML). The report that it provides is insanely detailed. I'd say this where the value of application-specific CQL queries would come in handy, because you can come up with some detailed queries that are run on every CI build to ensure that the code still matches whatever design criteria was decided upon when the queries were written.

 

For future versions of the tool, I'd think it would be neat to have a lightweight version of the CQL tool that you could ad hoc queries against assemblies, like as a Reflector addin or something. That'd be cool. Or maybe a Powershell cmdlet/PSDrive provider so that you could do something like this:

Get-ChildItem -Include *.dll -Recurse | Select-Cql -Top 10 -Methods -Where MethodCa -ge 5

Or maybe:

Get-ChildItem -Include *.dll -Recurse | Select-Cql -Top 10 -Methods | Where { $_.MethodCa -ge 5 }

I'm not sure exactly how the syntax might look, but it would be really cool

Hopefully, I've given you a good picture of the some of the features of NDepend. If your interest is at all piqued, there is a "Trial / Open Source / Academic Edition" that you can download for free. Its feature set isn't quite as broad as the Professional edition, but I've used it before and it still provides a lot of functionality. Check it out!

 

Full Disclosure - I used a review copy of NDepend for this post. My company is not (yet) using this tool, but I think that there is interest. I wasn't paid to do this. <kidding>If you, dear reader, would like to pay me, please contact me.</kidding>

 

^[1] I don't believe that all of the SKUs of Visual Studio have the Code Analysis feature.

I've found myself wishing that I could pass in more than two arguments to Path.Combine. That is, something like this:

Path.Combine(rootPath, someCalculatedPath, someKnownFileName);

As it is, Path.Combine only accepts two arguments, so I end up with calls that look like this:

Path.Combine(Path.Combine(rootPath, comeCalculatedPath), someKnownFileName);

It seems like a hassle to me. Here is a simple wrapper function (with accompanying test) that will accomplish this:

public static class FileUtils
{
    public static string CombinePaths(params string[] paths)
    {
        if (paths.Length == 0) return string.Empty; 

        return Path.Combine(paths.First(), CombinePaths(paths.Skip(1).ToArray()));
    }
} 

[TestFixture]
public class FileUtilsTests
{
    [Test]
    public void Should_combine_paths_correctly()
    {
        string expected = @"c:\some\path\to\file.txt"; 

        Assert.AreEqual(expected, FileUtils.CombinePaths("c:\\some", "path\\to", "file.txt"));
    }
}

This morning, I had my annual eye appointment and I completely forgot that they might dilate my eyes. Of course, my appointment was also scheduled first thing in the morning - essentially before work. Now, I'm sitting in front of my computer and literally everything is completely blurry. I can't read anything on the screen. It doesn't matter if I get close to the screen or far away, it is all blurry.

Enter ZoomIt! I initially heard about this tool from Scott Hanselman. It is another wonderful tool from Sysinternals (i.e. the guys that make Process Explorer, Process Monitor, etc.) so you know it is pure gold. The tool's primary use is to aide in presentations, so that you can easily zoom in to a portion of the screen so that people can see it better.

Today, I'm using it to just help me read the screen at all. I'm basically touch typing and periodically checking what I've written by zooming in to see if everything looks good. It is actually working pretty well, too.

Thankfully, the blurriness isn't lasting too long. As I'm writing this post, it has already cleared up considerably. Still, ZoomIt has come to the rescue for me this morning.

I was browsing around a few days ago and came across a link to a blog post on the SAPIEN website about searching live.com from PowerShell. Sounds cool, I think, so I download it to try it out only to be thwarted by the proxy at work.

There are a lot of scripts out there that use the System.Net.WebClient and the vast majority don't take proxies into account. To get around this issue, here's a simple script that I wrote to help out:

function Get-ProxyWebClient {
    $webclient = New-Object System.Net.WebClient
    $proxy = New-Object System.Net.WebProxy($global:ProxyUrl, $global:ProxyPort)
    $proxy.Credentials = (Get-Credential).GetNetworkCredential()
    $webclient.Proxy = $proxy
    return $webclient
}

This script makes the assumption that you've already predefined the $global.ProxyUrl and $global.ProxyPort variables in your profile. It is also nice for me because it prompts me for my credentials instead of having them hard-coded in the script or in my profile.

Now I can also check the weather from PowerShell using the Show-Weather script that the guys at SAPIEN provided in their über-prompt post.

I just wanted to share a Firefox extension I found recently. Stack Style Tabs basically treats the Ctrl+Tab shortcut in Firefox like Alt+Tab in Windows or like Ctrl+Tab in Visual Studio. I use Visual Studio all day long and I really like the ability to SEE all of the open files when I hit Alt+Tab instead of just cycling through them. It has frustrated me for a while that Firefox didn't provide this capability as well, but with this new extension, I'm set!

Here's a screenshot of it on my desktop:

Ever want to build Visual Studio solutions quickly, but without having to open Visual Studio or pulling up a command prompt and typing msbuild on the solution? You know, like right-clicking and choosing a build option?

Like this?

Just copy and paste the following into a file (msbuild.reg) and run it:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\VisualStudio.Launcher.sln\shell\msbuild]
[HKEY_CLASSES_ROOT\VisualStudio.Launcher.sln\shell\msbuild\command]
@="\"C:\\WINDOWS\\Microsoft.NET\\Framework\\v2.0.50727\\MSBuild.exe\" /target:Rebuild \"%1\""

Remember that this will only work on Visual Studio 2005 solutions. Because solution files go through a launcher to decide whether or not to open in Visual Studio 2003 or Visual Studio 2005, I don't know if you could specify for this to only apply to 2005 solutions.

Any ideas?

Read it here:  http://weblogs.asp.net/scottgu/archive/2007/04/03/expression-added-to-msdn.aspx

Woohoo!

This is a great move by Microsoft and I really appreciate it.

I wonder how many other people are firing up their blogs to post this, too.

The web has been busy with news about .NET 3.0 going RTM, along with Office 2007, Vista, etc. But some other news that hasn't received quite as much publicity is news regarding Sysinternals at Microsoft. There were a couple of posts today that I thought were very interesting.

The first post is about the move from the original Sysinternals site over to Microsoft. I think the best part of the announcement is the focus on letting the "community demand help drive [their] priorities." A few of the comments have been negative regarding the decision to not post the source code to the tools, but that is the only negative thing that I can see in the post. Besides, if people want the source enough, maybe Microsoft will put it back out again. They listened when people complained about the Vista EULA didn't they?

The second post is even better news. In addition to some new releases of some great tools from Sysinternals (mostly to support Vista), a new tool has been released called Process Monitor! Process Monitor takes all of the functionality provided by RegMon and FileMon and combines them with even more information such as information about threads! If you're worried that it will put too much into one place because it was nice to focus only on registry or file access, don't because with the click of a button, you can tell it to only display registry changes, file changes, or thread changes. If you want to get straight to the main Process Monitor page, it is here.

Here's a screenshot of Process Monitor in action:

Unrelated to this post, but I used the Snipping Tool in Vista to get this screenshot. It works pretty well.

Colin has raved about the joys of middle clicking for a while now, but I was never able to enjoy it because clicking my mouse's middle button never seemed to do all of the cool things that his did. Mine brought up a really weird multi-directional arrow thing that was supposed to let me scroll in any direction I wanted - except that it rarely worked the way I wanted it to.

Well, I finally decided it was time to fix it once and for all so that I could enjoy middle clicking like the rest of the world.

The mouse in question that I'm using is the Logitech MX700 *.

Here's what my mouse settings dialog looked like when it didn't work:

Now that it does work, it looks like this:

The difference is subtle, but all I did was change the functionality for the middle button from "Universal Scroll" to "Middle Button." That was way too easy for me to have missed it for this long, but I'm glad I finally found it. If you're having a similar problem getting your MX700 (or other similar Logitech mouse) doing middle clicks the way you want, check out what your setting is.

* - The Logitech MX700 is a great mouse that has a recharging dock so you don't have to buy batteries all of time... I've been using mine for almost 3 years without any new batteries. I can also highly recommend the Logitech MX1000, which I use at home. I plan on sticking with Logitech mice unless Microsoft ever releases a wireless mouse with a rechargeable dock. That rechargeable dock makes all of the difference.

I recently installed GhostDoc 1.9.5 on Vista RC2 at home. At first, I received as error towards the end of installation so I searched around a little bit to see if anyone else had seen the error. Then, as with most issues I've had with Vista, I decided to see if elevating the install to admin would work which seems to have worked fine.

The easiest way I've found to run things that don't offer a "Run as admin" option on the click menu (like MSI files) is to run the Command Prompt as an admin and then start the program from there. You can pull up the start menu, type cmd and then CTRL+SHIFT+ENTER which will run the command as an admin (thanks to Kristan Kenney for that info). Quite a nifty shortcut key for running as an administrator.

I was catching up on some older blog posts from different people recently and I came across some posts talking about how wonderful SlickRun is. Everyone is right, by the way, because SlickRun is amazing. It was probably the main program that moved me from being primarily a mouse user to a keyboard user. I still love how fast I can get around by taking my hand off the mouse and keeping them on the keyboard!

Anyway, I'm a beta junkie and I love finding out about new releases of software. I'd been looking for news on SlickRun for a while, but hadn't seen anything so I thought I would check out the SlickRun forums. I ended up finding this post where Eric notes that, because he is actually working on Windows Vista, the alphas for SlickRun probably won't show up until after the RTM for Vista.

Though I don't think a forum post carries nearly as much weight as a blog post on release announcements, I still have to say that I can't wait to see what Eric is working on for the new version. I'm looking forward to more from SlickRun!

I'm a big fan on Windows OneCare. I installed the betas and was thoroughly impressed at it. I recently posted in frustration, though, that the current version wasn't supported in Vista yet. Well, the 1.5 beta has now been released and it is supported under Vista. Here's a screenshot of it on my machine:

So far so good!

I recently updated my Vista installation to RC2 (build 5744), which went fairly smoothly for me. The installation went even better than for RC1, because I had moved my documents to my D: drive, so once I told Vista where they were, most of my initial configuration was done! I did have one weird problem with installation, but it disappeared when I booted from the DVD instead of attempting to install from within the previous install of Vista.

I ran into my biggest problem today, though, when I attempted to install Visual Studio 2005. I had downloaded the ISO quite a while back and had used it to install VS2005 first on Windows XP SP2 and later on Vista RC1 without any problems. Under XP, I was able to use the Virtual CD tool that Microsoft provides, but it wasn't supported under Vista. As a result, I had found the SlySoft Virtual CloneDrive, which worked great on Vista RC1. It didn't seem to work so well on Vista RC2 and I have no idea why.

The Visual Studio 2005 installation would fail with an error loading the file Rmt9x.mst. My problem sounded quite a bit like this one detailed on the MSDN forums, but I wasn't sure. I had also noticed some strange behavior with restarting since I had installed RC2, such as the restart hanging, even to the point of me having to power down my computer instead of waiting on the restart. On a hunch, I decided to uninstall Virtual CloneDrive and give DAEMON Tools a try. It helped that DAEMON Tools said that it supported Vista!

Once Virtual CloneDrive was uninstalled, I started up the DAEMON Tools installation which asked for a reboot. I was a little wary, but went ahead and let it and it rebooted without any hangs! First good sign!

After the reboot, I started up DAEMON Tools and pointed it to the VS2005 ISO and started up setup. The installation ran great, so everything points to something in Virtual CloneDrive not working as expected under RC2.

As I mentioned earlier, I still have no idea why Virtual CloneDrive began having problems under RC2. It ran great under RC1 and I really liked the interface it provided. DAEMON Tools is admittedly less user friendly, but it certainly gets the job done, which is what I needed.

Back in January, Gaston Milano posted a sort of wishlist for the next version of Visual Studio. One of the features he wanted was the ability to filter properties down in his Properties window. Here's a screenshot of what he had in mind (from his posting):

Well, I've got great news! Corneliu from his parallelthinking blog has created an addin to do just that! It works by using his Hawkeye application, which is a sort of superpowered Spy++ for .NET. Hawkeye allows you to attach to any running .NET application and inspect various .NET controls and their properties as well as methods, events, and all sorts of other fun things. With Hawkeye, you can even CHANGE properties and INVOKE methods! On the fly! And the other .NET application never even has to know about it!

His VS Properties Extender uses the functionality of Hawkeye to add a text box to the properties window at run time which allows you to filter to commands. It works great, too. Now I'm really curious what other sorts of functionality could be added to an application like Visual Studio by using Hawkeye. Check it out!

(found via Larkware)

Yesterday, I downloaded the Developer Productivity Tools video from the Wrox website that Scott Hanselman did for one of his presentations with a user group. He had a lot of great resources in the video but the command prompt tips he had were new to me. I've done some work with the console, but I've only recently been using it more, particularly with PowerShell coming along.

Scott's tip about customizing your prompt (from c:\dir\> to whatever) was really cool (also posted here). I knew that the prompt could be customized, but at the time I saw someone do it, I didn't have a good grasp of environment variables so it didn't really make sense what was going on, but Scott's video and his post have helped out a lot. They also prompted me to want to do the same with my PowerShell prompt!

The PROMPT environment variable trick doesn't work for the PowerShell prompt, but after a little digging around with Google, I discovered this post from Lee Holmes about the prompt function. If you have a function named prompt declared, PowerShell will use the value returned by that function to alter the display of your prompt. Here's my prompt function, which I have saved in PowerShell profile so that it will load every time (mine is located here C:\Documents and Settings\David\My Documents\PSConfiguration\Microsoft.PowerShell_profile.ps1)

# Initialize custom prompt
function prompt
{
   "PS " + (get-location).Path + [System.Environment]::NewLine + ">".PadLeft((get-location -stack).Count + 1, "+")
}

The only thing I haven't figured out yet is how to get a visual indication of how far in the stack you are (by using pushd and popd). Once I figure that out, I'll have a PowerShell prompt customized just like my cmd prompt!

UPDATE: I did some more research and discovered get-location -stack which will return everything on the pushd/popd stack. I've updated my prompt function accordingly. Now it matches my cmd prompt in every way!

Just a short note, but for those who have been waiting for a version of NDoc that supports .NET 2.0 assemblies, there is a separate project out on SourceForge called NDoc 2005. It is still in beta, but it may be the way to go until NDoc gets moving again. Per comments at MSDN forums, it looks like the best way to go is to download the source and recompile it yourself. The binaries (at least the GUI binary) looks like it still has some issues.

Note: unfortunately, it still doesn't completely work for me... *sigh*

(from DotNetKicks)

I don't like repeating myself, but I need to again: if you're not subscribed to the PowerShell blog, then why in the world not?!? The PowerShell team has been on top of it lately providing some GREAT one-liner PowerShell scripts such as listing all of the sub-directories from the current directory or, as in the case today, listing all of the PROGIDs that you can use to instantiate your own COM objects from PowerShell script.

Sure, the scripts are fairly simple and are clearly obvious once you see them, but it displays the power right at your fingertips that PowerShell gives you. Currently, I'm not using it for any projects. I'm just using it as a productivity tool! The parsing you can do with directories and files is great and you can very quickly leverage your knowledge of .NET in the process.

I can't help myself, PowerShell is great and I keep finding useful things to do with it. Most of what I've been finding is easily accomplished in other ways, but this just goes to show the power available straight from the PowerShell command prompt.

What if you want to know the full path to all of the solutions in a sub-directory?

You could try this:

PS C:\Dev>dir -recurse -include *.sln . | foreach { $_.FullName }

This builds on my post from yesterday.

Most of you probably are already aware of this little development, but there is a freeware IDE for PowerShell development (Scott beat me to the post...). It really is great. One of the most interesting parts about it, at least at first glance, is that it gives a first look at what an IDE might look like if it were to use Office 2007's ribbon. Not only that, but it even has an Mac OS X styled (or ObjectDock if you're so inclined) tool section in the bottom right.

Sweet!

I don't have much experience with XPath expressions. This was further illustrated to me recently when I was attempting to use XPath to programmatically parse an MSBuild project file. Yeah... I couldn't find anything. So, when presented with a problem, what do all programmers do? They write a program to solve the problem!

Here's a screenshot of my XPath Helper:

As you can see, I learned how to use XPath to parse MSBuild project files. My problem was not using XML namespaces correctly. XPath Helper attempts to automatically find XML namespaces and then add them to an XmlNamespaceManager (see the ListBox on the right - it lists all namespaces that it found). That way, when an XPath expression is used, it will know to use the XmlNamespaceManager. I'm confident that it won't work in all situations, but it is a nice learning tool to play around with XPath.

If anyone is interested, I can post the code... but if I do, don't count on it having any unit tests or anything. This guy is NOT production quality.

Anyone checked out CodePlex yet?

Looks like a Microsoft site for sharing open source applications, sort of like SourceForge, except a lot more user friendly! Apparently, it is built on Team Foundation Server, too. I just found the 1.0 release of MSBee (target .NET 1.1 with Visual Studio 2005) on there.

Check it out!

Many thanks to Robert W. Anderson for this solution.

In his post VS2005 PowerShell Prompt, Robert details how to create your PowerShell profile script which will add the VS2005 environment variables to the PowerShell process. Quite nifty.

As a note, after setting this up, you may get a message about how your script isn't signed so it won't run. One solution is to run "Set-ExecutionPolicy RemoteSigned". I wouldn't recommend going farther than that, though. It will allow local scripts to run unsigned and will warn you if a script that was downloaded tries to run. There are still vulnerabilities, so be careful. The other alternative is to sign your script.

I just found another nifty shortcut to finding items in Desktop Search. Let's assume you want to find an email with test in the subject in body. If you're like me, you'll find a ton of emails because you get to test a lot of code at work. HOWEVER, what if you know it was in the past couple of days? Try this then:

kind:mail test date:>5/1/2006

That will get all emails with test somewhere in it that came after May 1, 2006. Of course, you can narrow the search more by specifying test in the subject or body or whatever.

See my other tips and tricks here.

Thanks to Scott Hanselman for the heads up.

I've been using Consolas for a few months now and it is easily one of the best programming fonts I've ever used... and I've tried an awful lot of them... (see here and here for others).

Once it is loaded, start pimping your IDE.

I've really become a fan of MSN Desktop Search at work. I don't really use the toolbar at all, because I've got tabbed browsing in both Firefox and the IE7 beta, but the search features are great. I also like it better than Google's offering because the results don't pull up in a webpage. Even with all the buzz over AJAX lately, there is still a lot more interaction that can happen with a true client application.

Anyway, on to Desktop Search. It makes finding emails SO MUCH easier. The ability to use special search keywords makes it even better. For example, let's say I wanted to find all emails from me. Here's what I could do:

kind:mail from:David Mohundro

Voila! I now have all emails from me. The kind keyword lets you specify things like mail, pictures, documents, etc. If you want to get even more detailed, you can use things like the ext keyword and specify file extensions. Here's a search to find all icon files that have 'mail' in the name.

ext:ico mail

I haven't seen an all-encompassing list of all of the different keywords that you can use with Desktop Search, but there are quite a few if you'll look in the Desktop Search Help under Advanced Users.

And don't forget to use CTRL+ALT+M to get focus to your search box!

NOTE: If you're running into performance problems with it, check out this KB download. It really helped speed Desktop Search up on my PC. I couldn't work without it now.