I've used PDF-XChange Viewer for several years now and really like it more than a few others I've tried. But it appears that the Viewer has been discontinued in favor of their commercial PDF-XChange Editor. This is unfortunate (for users looking for freeware). But at least they still allow you to download the Viewer (for now).

You had me at hollandaise!

We use TFS 2010. I've spent some time customizing the Build Process Template (it's just Workflow XAML). We have a pretty smooth build and drop process (our Sys Admins migrate the files from the drop folder to QA and Production). TFS seems to be designed more to build the software rather than deploy it - there are often misconceptions that building and deploying are one in the same. Deploying often involves a change control process and TFS just doesn't have the audit capability to that level. The biggest challenge we've had is less technical and more political. Once we get the Sys Admins to fully buy into the idea of a build server then we may be able to convince them to adopt an automated deployment tool.

Just out of curiosity (forgive me if I missed a few details in the many posts here), is the introduction of Version Control supported by the stakeholder(s)? In my experience, VC is the type of mechanism that can only be introduced if the stakeholders insist. Developers who don't already use it on their own must not actually be interested in it and probably won't be convinced by selling points presented from one of their own (assuming I understand your relationship to them). I would think the sales pitch to the stakeholder should be pretty straightforward - as far as they're concerned it's the same need as buying insurance for any aspect of the business. The mandate to introduce this MUST come from above. The questions of "Which VC platform?", "What branching model?" and "What best practices should we adopt?" are more of the issues that should be discussed among the development group (although still assuming some sort of management decision would be needed to make the outcome official).

Chuck Norris can divide by zero.

I was on a team a few years back tasked with writing coding standards. We started to define prefixes for all commonly-used types and user controls. We quickly realized that there were just too many variations for us to account for in modern Object-oriented systems. This includes dozens (or hundreds) of classes as well as custom subclassed UI controls. Additionally, Visual Studio (and other IDEs) are kind enough to display tool-tips indicating the data type. I also frequently use the "Go to definition" feature to further explore the origin of variables or types. It's important to remember that the type of some variables can change over time (i.e. Int32 to Int64 or Double to Decimal). Coupling the variable name to its type just increases the potential need for future refactoring that could be avoided by simply using a more generic (but still descriptive) name. I realize the big exceptions to the IDE-sugar are when you print code or view it in a plain text editor. But what my team decided is that these were very rare in our situation. We ended up recommending a "good descriptive name" for variables and UI controls. We realized that with the Intellisense-driven Visual Studio experience you only have to type a variable or control's name ONCE (in most cases) and Intellisense will assist with all subsequent references to it.