Ok, the title is vague, but there's only so much I can put in a title, right?

As per MSDN's documentation for the Microsoft.SharePoint.WebPartPages class and Andrew's post on v3 web parts, we should now inherit from System.Web.UI.WebControls.WebParts.WebPart when we are building custom web parts, except in the four scenarios he mentions (repeating here for my own records):

1. Cross page connections
2. Connections between Web Parts that are outside of a Web Part zone
3. Client-side connections (Web Part Page Services Component)
4. A data caching infrastructure that allows caching to the content database

However, I came across a situation recently whereby a very simple custom web part (all it did was render a "Get Adobe Acrobat" link, essentially) threw a SharePoint error to the screen when used in conjunction with Variations. Here's the steps to replicate:

1. Create your custom web part, inheriting from System.Web.UI.WebControls.WebParts.WebPart. Keep it simple; "Hello World" is fine.
2. Build/deploy, etc. Use it in one of your page layouts. Of course, Variations has to be set up/enabled, but turn off automatic creation of target pages.
3. Once the new page has been created, select either "Update Variations" from the Tools menu.
4. SharePoint will start a long running operation, and then eventually throw an error to the screen.
5. The target variation page is actually created, but this error message is annoying, and probably discomforting to the authors.

It took me a while to figure out what was causing the problem. I finally had a thorough look in the SharePoint logs, and found the message that told me the cause. If you are using SpsDev's ULS Log Reader, filter by Area:CMS, Category:Publishing, or just look for the message "Unable to cast". The relevant part of the message is:

Unable to cast object of type '******.Website.SharePoint.WebParts.AdobeLinkWebPart' to type 'Microsoft.SharePoint.WebPartPages.WebPart'

Um, what? Why does it want to do that? So...

1. Re-write the web part to inherit from Microsoft.SharePoint.WebPartPages.WebPart.
2. Create a new DWP file to match.
3. Deploy, etc; re-test.
4. Of course, it works without the error.

Microsoft's own web parts that inherit from System.Web.UI.WebControls.WebParts.WebPart don't seem to have the same behaviour. Nevertheless, I believe this to be a bug, but one that you should know about when using custom web parts in conjunction with Variations.