Just thought of sharing my experience last week with SharePoint 2013 projects built with TFS.
Create a QA Build (to do releases to QA) for a solution with SharePoints projects. Version number of each assembly must be changed as specified below.(How to version number change with TFS is here)
Version number should be in x.x.x.x format and last number should increment by one in each QA build. Example if first version build assembly version number is 18.104.22.168 then in second it should be 22.214.171.124. (I used my own build template to do this but you can do this as described here)
All went well and my TFS Build created necessary .wsp files in build drop.
Where it went wrong?
When .wsp files deployed to SharePoint it deployed, but creating a site collection utilizing .wsp files gave famous "Something went wrong" SharePoint error. One sleepless night to diagnose the issue with no luck with my little knowledge in SharePoint (believe me it was a huge SharePoint product I was dealing with and I do not still have a clue how share point works :) , I was doing only my part use TFS and get a build working )
Tried with a build without changing version number and all went well. huh! then this is about version numbers? Had a good look at that "Something went wrong" page. Aha..In url it had some mentioning cannot load assembly with reflection.
What was the solution?
Simply modified my build template to change only AssemblyFileVersion without touching AssemblyVersion. It did the trick and I could successfully deploy the .wsp s built with TFS - version number changed (only AssemblyFileVersion), and use them in a SharePoint site creation.
Further investigation to code base lead to find the culprit. It was SharePoint Feature, ReceiverAssembly syntax. The experts in SharePoint told me it is the way it is, and they did not like my idea of TFS Build manipulating these files to change version number here as well :( . (My ideal solution)