Recently I've been working on an explorer like application made up of a TreeView of folders, SplitContainers, ListView of items of interest and various TabControls.
TreeView, by default, hides the selection when the control loses focus. This can make it hard for users to determine which folder they're currently browsing when they click on any other control. Fortunately TreeView.HideSelection handles this by changing the background to SystemColors.Control when the control loses focus.
Ditto for ListView.
Drag and Drop is, in general, a LOT easier to use in Windows Forms than it was under MFC or even VB. However, it looks like there isn't built in support for changing the background color of nodes while the mouse hovers over them during a Drag and Drop operation.
Also, expanding the node under the mouse after hovering over it for a while during a Drag and Drop operation isn't built-in. Considering how convoluted that description is, it's no wonder!
BackgroundWorker is an absolute godsend! I'm glad I forced myself to use it. Make sure to save updating the UI for the progress event. Although it doesn't do anything you couldn't do manually (with a separate thread or the threadpool) having it available freed up time to handle other application related tasks (like interruptible directory scanning).
Bitmap.FromFile() will maintain a lock on the file; in my case this prevented as-you-go temp directory cleanup so used a MemoryStream instead.
ImageLists - Resizing destroys the underlying handle which resulted in ListView failing to render the images at the new size. The workaround I adopted was to copy the Images into a new ImageList (one created with the correct size). Suprisingly this ends up being more than performant enough for this application. Use a double-buffered ListView to reduce flicker.
Speaking of ListView, for reasons I haven't had time to determine, small icon view can render incorrectly when non-standard icon sizes and long item names are used. Oddly enough, it appears that the widths set for ListView.Columns elements, which shouldn't impact small icon view at all, seemed to effect the size allocated by ListView for each item. Since details view also has the small icon along with SubItems, I decided to drop small icon view in favor of details view.