Disclaimer
I realise the solution I mention below is frowned upon by alot of dev ops people, but in my experience it it by far the simplest and most reliable way to solve the issue.
Solution
By far the easiest solution to this issue is to install Visual Studio 2012
on your build server. I know you've said that the infrastructure team are not keen to do it, but IMO it's a best practice. I'll try to outline why below.
Installing Visual Studio on your build server seems like a strange thing to do, but having been around the TFS
block a bit, I have found it to be the simplest way to manage build servers.
You can copy the files (targets) manually from your dev machine to your build server, but if an update to visual studio comes out, you will need to figure out what has changed and make sure you update all those files too. These files typically include Targets files and associated dlls.
Also with all the extensions and packages that are available now, it is just easier to load Visual Studio on your build server and install the required packages than try to work out what is needed to replicate the functionality.
This was made very clear to me recently when Microsoft released ASP.Net and Web Tools 2012.2
. This altered the publishing pipeline for Web Sites and Web Projects and I needed to use this in my TFS build. It was so much easier to just be able to log onto my build server, load Visual Studio and download the new update.
I would definitely support installing Visual Studio on your build server.