The insidious link between TFS Version Control and Error MSB3491

Scenario: You have retrieved a bunch of projects from VSS to migrate by hand to TFS Version Control.

  1. You Get the code from VSS, build the solution and run the tests. Everything is working out fine and all tests pass
  2. You bring the projects int TFS using the source Control Explorer’s Add Files button.
  3. You select the root folder of the project to add.
  4. Once you have all of the project folders in the Add files dialog, you click Ok and voila! all of your projects are in TFS.
  5. You get ready to test the migration by cleaning the source code folders from your drive.
  6. You perform a Get Latest from TFS. All the source is pulled down to your PC
  7. You open the solution in VS and build
  8. Many, if not all of your projects fail to build.

What you see in your logs is something like this:

—— Build started: Project: TraceListeners, Configuration: Debug Any CPU ——
TraceListeners -> c:projectscommonDiagnosticsTraceListeners_2_0binCommon.Diagnostics.TraceListeners.dll
C:WINDOWSMicrosoft.NETFrameworkv2.0.50727Microsoft.Common.targets(2797,9): error MSB3491: Could not write lines to file “objTraceListeners.vbproj.FileList.txt”. Access to the path ‘c:projectscommonDiagnosticsTraceListeners_2_0objTraceListeners.vbproj.FileList.txt’ is denied.
Done building project “TraceListeners.vbproj” — FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========

Issue: As you can see, MSBuild is trying to write to the *.vbproj.FileList.txt file in the obj folder, but access is denied. If you look at this file on disk, you will notice that it is marked as read-only. No big deal, just turn off the read-only flag. You do this and rebuild, but the build passes. Very good! You go home with a nice case of the “warm fuzzies” and sleep like a baby. In the morning you come in to the office to find that the nightly build broke with the same exception. You look at the *.vbproj.FileList.txt file and it is read-only on the build machine. You scratch your head and let out a expletives and then delete the entire obj folder. Then the nightly build is run again and if fails again damn it! Oh look, the *.vbproj.FileList.txt file is back to read-only. Sounding familiar yet?

Problem: The build fails because the *.vbproj.FileList.txt file is read-only so MSBuild can’t write to it.

Reason: The file is read-only because you checked the obj folder into source control in SteWhenevernevery you do a Getsourcesoruce control, the files are placed on the drive as read-only. The nightly build is configured to delete the prior run’s source code (or should be) and Get from source control prior to building. Therefore every nightly build fails in the same way.

Solution: Delete the obj folder from source control and check-in the change. That’s it.