This is probably a big duh for some of you out there, but if you're running the remote debugger that comes packaged with Visual Studio 2008 (you can find it at C:\program files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger) on a remote machine and you try to attach to that remote machine using Visual Studio 2005, you'll get an error. In fact, VS2005 will tell you that it can't find any servers running on the remote machine. All afternoon yesterday, I was trying to figure out how this one users' security was wrong and keeping me from attaching to a remote debugger he was running when, in fact, I just had an older version of Visual Studio trying to talk to a newer remote debugger.

*sigh*

Maybe now I can figure out what the original problem I was trying to debug was in the first place.

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.

In case you've been under a rock recently, Visual Studio 2008 was released recently which supports a lot of functional capabilities like lambda expressions. I've been playing around with the lambda syntax in both C# and VB.NET recently and the addition to the languages is great. I did run into one thing that is still frustrating me in VB.NET, though.

Check out the below C# snippet:

TryTimes(() =>
{
   Console.WriteLine("hi there.");
   throw new Exception("haha");
   Console.WriteLine("hi there after   .");
}, 5);

This is the prototype for the usage of a function that could try an operation a certain number of times and then fail if the operation didn't succeed after N number of tries. Obviously, the above code sample will fail every time, but the idea could work alright for file I/O if you're unsure if anyone else might have locks on the file.

The above is impossible to do in VB.NET, though, because VB.NET does not support multi-line lambda expressions. The C# supports them by wrapping the expressions in curly braces, essentially making the lambda expression a block. I wanted to emulate the same thing with VB.NET, but after some fruitless web searches, I came across this MSDN forum posting on VB.NET and lambdas which then pointed to Paul Vick's post on the VB 2008 features that are still in.

I've been wanting the equivalent of anonymous delegates in VB for a long time and I thought, with lambda expressions, I might finally get them. We are a lot closer, but they still don't provide quite the benefit that they could have had we gotten multi-line lambda support. I guess those annoying line continuation characters in VB mess this all up. I think if I could change anything about VB, it would be to make those optional.

On the positive side, though, the intellisense support for VB.NET has increased substantially. For that, I am thankful.