title: Visual Studio TFS integration for Qt applications
body: <p>We're developing a Qt application that needs to be built on both Linux and Windows hosts. On Linux we'll be using Qt Creator, and on Windows we'll use VS2013 with the Qt plug-in.</p>
  
  <p>The workflow we're using in Visual Studio is to open the Qt .pro file, and allowing the VS plug-in to generate the solution and project files. If another developer makes changes to the project, I would get the latest source from TFS, then open the .pro file again, and allow the Qt plug-in to regenerate and overwrite the VS solution and projects. We're not storing the VS solution/project files in TFS.</p>
  
  <p>The problem is that now we're not integrated with TFS. Modifying a file in one of the solution's projects does not automatically check out the file for editing. The solution for this is to bind the solution to to a project in TFS.</p>
  
  <p>How does this work when the solution will be regenerated on a relatively frequent basis and probably break the binding? Do we have to rebind it every time?</p>
  
  <p>It appears that trying to bind to source control fails, too. Of my solution and the two projects it contains, when I try to bind them to TFS only one of the projects says that its binding is valid. The solution and other project say "invalid", and of course don't give <em>any</em> information about why it's invalid. <em>It turns out that the solution and project files need to be in TFS for the binding to work.</em> Once I tried that i can bind them. (This doesn't explain why one of the three would properly bind...)</p>
  
  <p>The real question here: <strong>What is the recommended workflow for this scenario?</strong></p>
  
  <hr>
  
  <p>Some additional information: Originally, the workflow was to have a set of .pro/.pri files for use with Qt Creator on Linux, and a set of .sln/.vcproj files for use on Windows. However, it appears some build-machine specific settings are included in the VS project files that cause builds to fail on different build machines. I read somewhere (can't find it now) that the preferred workflow is what I described up above the break.</p>