It was (up until today) located @ http://tfspasteattachment.codeplex.com/

Since the functionality had been removed from the product during Whidbey, the codeplex project was an add-in that added it back for people still using Visual Studio (more specifically, Team Explorer) 2005.  However, since the functionality went back in with Orcas (TFS 2008) and that’s been out so long, there’s not much reason to keep that project around any longer.

I had added it back during the Whidbey development cycle to scratch my own itch – I was filing lots of bugs during our bug bashes, but I got sick of how much time it took me to get screenshots or logs attached to the bugs I was filing (bugs filed without logs/screenshots/etc make me quite sad).  Back then you didn’t bug bash on your own machine (mainly due to the 2.0 CLR being still a work in progress at the time and the logistics around that – this was before Hyper-V :), but TS’d into a remote machine (very remote for those of us in North Carolina! :) – since it was remote, I even noticed people that didn’t know about mstsc’s clipboard-transfer capabilities saving files on the remote machine then copying them to their desktop machine to attach to the new bug (ouch!)

Getting the data I wanted to attach to the bug into the clipboard was pretty simple:

• For a file, copy it from Explorer
• For some text, copy the text
• For an image (screen shot), capture it (I was using OneNote’s screen clippings feature and still use it today)

During my existing bug filing, I found I would either paste the file(s) to my desktop and attach them from there or for text or image data I’d open notepad or mspaint, respectively, paste it in, save it to a file on my desktop, and then attach that file (then delete the file after I had saved the attachment to the work item).  Lots of manual work, unfortunately, and if I forgot to delete them, random temp files laying around my desktop.

So the question was then “How do I get this data from the clipboard into an attachment on the work item with less steps?”

The clipboard part ended up being ridiculously easy thanks to the great static methods available in the BCL’s Clipboard class.

The other part, getting it onto the work items, was pretty straightforward as well thanks to the Attachments property off of WorkItem.  The rest of the code (hooking into the attachments UI control, for instance) was also straightforward thanks to help from Jason Prickett who was on the Work Item team at the time (and right down the hall!).

To use

As you’d expect, the user interaction is that of “pasting” (control-v by default) into the attachment control.  You can do this with files (1 or more), text, or image data in your clipboard and it’ll attach it to the work item.  In addition, for the particular case of files you can drag-drop them as well.

Adding files (this via control-v of files that I control-c’d in Explorer)

Adding text (this via control-v of text that I control-c’d in notepad)

Adding screen shots (this via control-v of an image that I captured via Win+S with OneNote – incidentally, that’s also how I make the screen captures for blog posts)

It was a little disconcerting that I can’t even successfully send feedback.  Now, I’d be happy to report that I had a failure trying to send feedback, but where’s the link for that? :)  Back to manually filing a bug, I guess :)

To compound the pain, the above instructions aren’t even correct.  PowerShell is part of the OS in Vista (it installs with CBS, not MSI), even if it’s not “in-box”, so you have to go “turn off” PowerShell – it’s not a regular program you would uninstall as the compatibility report seems to indicate.

I’ll hold out hope that it’ll be better by RTM!

It does raise a related question, though: What’s the opposite of a Snoopy Dance?

Incidentally, once I searched on 13.820 I noticed a comment left by MikeH2005 that confirms the SP1 update of Virtual Server 2005 R2 includes the same 13.820 version (and is what's needed for Win7), so if you're running Virtual Server, then SP1 should fix you up as well.

Download links to get the SP1 updates:

• Virtual PC 2007 SP1:
• http://www.microsoft.com/downloads/details.aspx?FamilyID=28c97d22-6eb8-4a09-a7f7-f6c7a1f000b5&displaylang=en
• Virtual Server 2005 R2 SP1:
• http://www.microsoft.com/downloads/details.aspx?FamilyID=a79bcf9b-59f7-480b-a4b8-fb56f42e3348&DisplayLang=en

It turns out this xkcd comic is a little behind the times - we de-Hitler'd over 5 years ago!

Others seem to have run it with no problems, and I installed it and ran fine (installed the update as well, even though there wouldn't be any mp3 files on that VM).  However, attempting to install the VM Additions (VPC 6.0.156.0) resulted in a busted driver.

Bonus points if you happened to notice that incorrect use of "it's" instead of "its" in the highlighted error message.

I'm not the only one hitting it, at least... but as I type this, it's the only hit by my search.

http://betaarchive.com/forum/viewtopic.php?f=32&t=6664

Since others at least claim to have it working under VPC 2007 fine, I'm not sure what's different about ours (host OS for me is up-to-date Vista), but for now I'm having to stick without VM Additions (System Restore worked great! :), which is pretty painful.

Since I have to System Restore in order to get back to bootable, I'm guessing the relevant memory dump / WER data isn't getting sent, but I haven't dug into that as of yet.

Go get it!

The bits in the overview I want to call out (because I've seen others trip over this) -

• In Windows PowerShell V2 CTP, the WS-Management-based remoting features work correctly only on Windows Vista with Service Pack 1 (SP1) and on Windows Server 2008. These remoting features will not work on Windows XP and Windows Server 2003 in this release.
• Windows PowerShell background jobs (jobs) rely on the remoting features of Windows PowerShell V2. To use jobs, Windows PowerShell remoting must be enabled, even if the job runs only on the local computer.
• Many features introduced in previous CTPs were modified based upon customer feedback. If your scripts used those features, they may have to be modified to run properly. A list of the changes is provided in the Release Notes.

You really want to play with the jobs support.  Before I started playing with it, I expected something akin to job control from bash (and many other shells), but it's much more than that - among other things, its built-in support for running jobs remotely and throttling.  Check out this post from MoW for an example.

If you're new to PowerShell V2's remoting, you may also want to read Don Jones'  article and Krishna's blog post for a quick conceptual overview.

So, time for a quickie one-liner and then paste the resulting text into the IM window to see what the alphabet emoticons are:

Note that it's a little annoying (again, to me) that I can't do char ranges (at least with V1) that I can do with something like perl (and many other languages)

# perl -le "print 'A'..'Z'"
ABCDEFGHIJKLMNOPQRSTUVWXYZ

# 'A'..'Z' | %{ '( {0} ) == ({0})' -f $_ }
Cannot convert value "A" to type "System.Int32". Error: "Input string was not in a correct format."
At line:1 char:6
+ 'A'..' <<<< Z' | %{ '( {0} ) == ({0})' -f $_ }

Flash does this for me on sites like Hulu where I typically want to throw up last night's Colbert Report on a monitor while continuing to work on a second monitor.  No luck, though - any actual clicking after clicking full-screen (like, to shift focus back to another app) kills the full-screen.

Same for silverlight, unfortunately.  For instance, hitting the Getting Started video, I wanted to have it full-screen on one monitor and play around with silverlight in VS on the other.

In the silverlight case, at least, the video is also available in other formats, so I can open the wmv version in WMP, either standalone or in the browser (so any argument of "browser plugins can't shouldn't behave that way" is gone, IMHO) and at least *that* app doesn't exit full-screen when other things are done on another monitor.

It's almost 2009 people!  Let's have some more love for multi-monitor setups!  Silverlight 2.0 having this behavior really strikes me as odd (and a little disappointing).  Maybe the key Silverlight people are all rocking laptops and don't have this problem like I do :)

Are others hating this behavior like I am?  Sure.  Enough to change the behavior?  Given how long Flash has called this By Design, I'm not very hopeful for that plugin, but maybe Silverlight can at least change, although since 2.0 has already shipped, it'll probably be awhile even if it does :)

• http://www.wowzamedia.com/forums/showthread.php?t=3319
• http://help.youtube.com/group/youtube-howto/browse_thread/thread/4687210aef758024
• Note that here a guy from YouTube says this is By Design behavior for the plugin because of a security issue, but I'm personally not buying that argument, especially in light of the multi-monitor trade-off it causes. 
• http://msdn.microsoft.com/en-us/library/cc189023(VS.95).aspx
• It goes double for Silverlight, since "A Silverlight plug-in can enable full-screen mode only in response to a user-initiated action" (for all I know, that may be true for Flash as well).  As that page mentions, this specifically avoids the Flash security argument - "This prevents malicious applications from spoofing the appearance of the operating system or other programs."
• However, this same page says the current behavior is By Design
• "A Silverlight plug-in in full-screen mode can lose focus in a multi-monitor configuration when another window gains focus through a user action"
• http://www.phwinfo.com/forum/macromedia-flash/280820-flash-player-full-screen.html
• This mentions an offline app that will get you the behavior, but IMHO that's a ridiculous workaround to push onto the customer

Don't get me wrong - there are plenty of other offenders in this bucket (DreamScene, for instance, pauses on all monitors when there's a window is maximized on any of them), but Flash and Silverlight are the ones that cause me the most daily pain :)