This post has absolutely nothing to do with anything. Just some ramblings from my brain this morning.

I got to work a few minutes ago and the first thing I do every morning is go pour myself a cup of coffee. The coffee doesn't bother me too much - at least after I pour some sugar and cream in it and it looks more like milk than coffee. However, others at work despise the stuff. It's the typical coffee you might find at any other corporate office... except maybe Starbucks.

That's when the ironic thought hit me.

What if the coffee that Starbucks has for their employees is the same coffee sludge that every other corporate office has? Wouldn't that be hilarious? Wouldn't it be... ironic?

It must be too early in the morning to form coherent thoughts.

I've already shared with you about how cubicles really can be annoying when you sit next to the loudest two individuals in the world.

Now, I'd like to point you to a video that Long Zheng posted (from istartedsomething) from when Conan O'Brien visited Intel headquarters.

Here are some similarities between Intel and where I work:

1. Cubicles really are like parking garages, except that you have assigned spots.
2. Cubicles really don't have much color or individuality (I do have a National Geographic map on my cubicle wall, though - yay!).
3. People really are picky about their chairs. Seriously picky.

Here are some differences between Intel and where I work:

1. No cafeteria.
2. No "ultra-clean" factory.
3. Hairnets only come into play on Halloween.
4. I haven't ever seen kids on a field trip, though we do have kids come around our cubes to sell cookies sometimes (and on Halloween).

One other thing - I think I've met Bill Lumbergh's clone in our cubicle farm. I'm guessing any and all work environments that make use of cubes have their Bill Lumberghs.

I just finished reading this post from the BCLTeam blog on the Silverlight 1.1 Alpha release that was announced at MIX07. It sounds like there is a new security model that is being introduced with Silverlight as a replacement for CAS (Code Access Security). I haven't done any research yet, but it looks like we'll be able to just decorate methods with attributes like Transparent or SafeCritical.

From just a cursory glance, it sounds like this will be much easier to work with than CAS. I couldn't ever really follow CAS very well - usually I just followed the FxCop guidelines and left it at that. I found the MSDN documentation on developing Silverlight applications with the .NET Framework, but there isn't much on the security side of things yet. I'm interested to see if Microsoft will start to move away from CAS to a more developer-friendly model.

Sounds interesting.

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?

Scott Hanselman recently posted about a bug that can occur when using Firefox as your default browser. The root problem deals with Outlook trying to start up Firefox using DDE instead of just a simple command line argument. At work, we ran into a very similar situation, because we were wanting to open up URLs in the default browser from our application. Normally, this would be easy because all you would have to do is Process.Start the URL without providing an application and ShellExecute would handle the rest for you. Needless to say, this wasn't going to work for us because we had overridden the default open action for URL shortcuts with our own action (it's a long story that I won't go into in this post).

Our solution started with pulling out the default browser from the registry (we still kept the original open action command, see HKEY_CLASSES_ROOT\HTTP\shell\open\command). Once we have the value, we thought we would be able to Process.Start the command line from the registry passing in the specified URL. We tested it out in Firefox and everything worked great. Even better, Firefox would reuse windows based on the user-defined settings.

Not so with Internet Explorer. Internet Explorer would open the URL for us, sure, but it would not respect the user-defined settings on the reuse of windows. This was confusing to us, because Outlook was smart enough to get Internet Explorer to reuse windows. The question was how it was happening... and that's where DDE came in.

When Outlook opens a URL shortcut, it connects to the DDE IExplore server on the WWW_OpenURLNewWindow topic. If he is able to connect, then Internet Explorer is already running. He then sends an XTYP_EXECUTE transaction passing along the URL. If everything works correctly, then Internet Explorer will open the new window and bring it to front for you. If no Internet Explorer instances are running, Outlook will start a new instance.

In case you were wondering, this was all verified using DDESpy (which you can find in the Visual C++ 6.0 Tools installation... if you still have it). It was also tested against Internet Explorer 7 and Outlook 2007 which means this information is still current.

And yet, Raymond Chen has encouraged us to stop using DDE, because "DDE has been dead as a shell interface for over ten years." Oh how I wish that the Internet Explorer team knew that. If they had, we wouldn't have had to code up DDE to get similar behavior in our application. And let me tell you, DDE is not fun to code against. There are very few resources covering DDE on the Internet (probably because DDE died before the Internet became really widespread... or not).

I'm sure you've seen this page before:

I've seen a million posts on it, too. Jeff Atwood posted about this problem when he was talking about user-friendly 404 pages. Internet Explorer tries to hide ugly error pages from you unless the page displayed is greater than 512 bytes in size.

I used to have this setting turned off, but my employers recently pushed out Internet Explorer 7 to the corporate masses. I already had it installed, but it apparently went over my previous installation, which means that I lost my previously customized settings. Anyway, I spent about an hour trying to figure out why my IIS installation had CustomErrors turned on for everybody before I realized that it was actually Internet Explorer helping me out.

To turn the setting off, go here:

As Jeff points out, the best solution is to make sure that your error pages are bigger than 512 bytes. Most of the time, ASP.NET error pages are far larger than 512 bytes, too. HOWEVER, error messages from HTTP Remoting* are NOT always greater than 512 bytes and I'm not sure if you can customize those or not. So I like to just save myself the headache and turn this off.

* As a note, a useful tip for debugging HTTP remoting applications is to browse to your registered channel (i.e. http://localhost/remotingEndPoint.rem) with a browser. If there are any problems with your remoting configuration or with your assemblies being loaded, you'll get the friendly ASP.NET error message displayed to you. If you don't get an ASP.NET error, you'll usually get a message that looks like this:

System.Runtime.Remoting.RemotingException: Requested Service not found

It basically means that you're configured correctly and that the server didn't find a service based on your HTTP GET. I prefer checking remoting servers this way because it is easier to read messages in your browser than trying to interpret a binary serialization exception while in your remoting client.

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.