Quoting some comments in Jeff Atwood's "Revinventing the Clipboard" blog post:

What I dislike the most, about the clipboard, is the really bad behaviour in VS. Say you cut something, then you try to past it elsewhere but you hit the C instead of the V (without any text selected) and bravo, you've lost your clipboard content! You now have to undo 3 or 4 times to re-start the manipulation. This is anti-productive at the most.

Fabian on January 22, 2008 03:01 AM

Fabian: That one gets me too, but the good news is that you can turn off that behaviour in Visual Studio.

Go to Tools->Options...->Text Editor->All Languages->General and untick "Apply Cut Copy commands to blank lines when there is no selection"

(I guess this goes towards what Jeff was saying about software having reasonable defaults).

GrahamStw on January 22, 2008 03:10 AM

It's one of those things that I never remember how to reset so here it is. Glory Hallelujah.

And btw, using ClipX and loving it (and yes, the beta seems to work fine in Vista).

In Visual Studio 2005, the default is to not automatically insert attribute value quotes when typing in the HTML editor. I don't like that. If you're like me, change this default behaviour by going to Tools -> Options -> Text Editor -> HTML -> Format. Then check off "Insert attribute value quotes when typing."

On another note, you'll notice the "Insert attribute value quotes when formatting" checkbox right below. This is on by default; I find it very useful in that one of my favourite shortcut key chords (ctrl-K, ctrl-F) not only formats the selected text, but also then automatically enters any missing attribute value quotes.

Many of the ASP.NET web applications we build use SMTP to send email for one reason or another. Order confirmations, mostly, or selected search results.

Testing code that sends email has always been a pain. We have servers with SMTP service that I could point at from my development workstation, but their various restrictions have been, well, restricting. Nor did I ever like the idea of letting SMTP run openly on my local machine in XP. Not that I had much choice, because a) I had to ensure that the code I wrote followed through with the email send, and b) I wanted to view the email as email to ensure it looked the way it ought.

So along comes Vista with IIS 7. And SMTP is not included. It is included with Longhorn Server 2008 with IIS 7 (apparently), but not Vista. I now no longer have the choice of running SMTP locally. Disaster!

Well, as it happens, I'm fine. I'm better than fine, because I stumbled across a better solution all around. I use a pickup directory location.

Using a pickup directory location lets me specify a folder on my local machine for the email generated by System.Net.Mail. It's not sent anywhere, it's just dumped in that location as a *.eml file which can be viewed by Vista's built-in Windows Mail.

The best thing is, I don't have to change my code in any way to make this happen. I only need to add a snippet to the web.config as follows, identifying the (absolute) directory for pickup:

<system.net>

  <mailSettings>

    <smtp deliveryMethod="SpecifiedPickupDirectory">

      <specifiedPickupDirectory 

pickupDirectoryLocation="v:\inetpub\mailroot\pickup"/>

    </smtp>

  </mailSettings>

</system.net>

I did have to make sure that the ASP.NET worker account, NETWORK SERVICE, had read/write access to that location.
And here's the result. One double-click and I get to see it as it would appear in my inbox:

Probably other developers are like, well *duh*, but this was a new and very pleasant discovery for me.

Mentioned first a couple posts back, there is now a public hotfix patch available for debugging ASP.NET on IIS7 that you can download here. The reason for this post is that Scott Guthrie just wrote a post that gives a much better explanation of the problem and fix.

Peter beat me to the post already, but instead of just leaving these thoughts in the comments, I figured I should add my two cents in a dedicated post as there a couple other things to take note of if a) you're not running as an Admin in Vista and/or b) you want to debug easily with Vista and IIS7.

First off, before hitting Peter's post, go to ScottGu's post. It tells you the essential step of making sure you've installed the "IIS 6 Management Compatibility" option within IIS7 (as ScottGu states, it "installs an API for the new configuration system that is compatible with the old Metabase APIs (which is what VS 2005 uses)").

As well, it'll help you if you've continued to run as a non-Admin on Vista with UAC enabled (both Peter and I have given up on this and are running as Admins with UAC off - the horror). I attempted for a month or so to use Vista with UAC etc., but the deal breaker was when I discovered that I couldn't drag and drop files into Visual Studio; nor could I open a project using the sln file. I'll hold off on UAC until stuff like Visual Studio is upped to use it reasonably (however, for those that want to use this as another reason to slam Vista, my love-hate relationship continues, but whenever I have to do something on my WinXP machine, I cringe...thus, there's a whole lot more love right now than hate).

In addition, I've found that in order to enable debugging, I need to add the following two steps:

1. Set your application pool for the site to the Classic .NET AppPool.
2. Enable Windows Authentication so that you can debug the site (haven't taken the time to figure out why this particular combination works, but suffice it to say, out of all the posts out there explaining how to get going with debugging with IIS7, this is the only thing that really matters). You'll get a "Challenge-based and login redirect-based authentication cannot be used simultaneously" alert, but ignorantly ignore this and you'll be fine.

UPDATE: I just found out in the writing of this post, that there is now a Visual Studio patch that fixes the Visual Studio F5 debugging of IIS7Applications on Vista.

NOTE: I LOVE being able to run multiple sites at one time. Bliss!