I always understood that best practice was never to check into TFS binary (e.g., bin and obj) files.
A while ago, someone in our implementation of TFS did not adhere to this, and checked in the bin and obj folders.
Thereafter, when I try to GLV code to a new machine, TFS downloaded all the project folders including items such as bin, obj, Debug etc and temp files like .dll, .cache, pdb. Then, when I run Clean Solution, TFS removes such files inside these folders, but then, when I Build, I get errors that there are dll files missing in obj\Debug folder.
To fix this, I then took the following steps:
I undid current changes so that TFS had nothing checked out.
I deleted the bin and obj folders from Source Control Explorer within TFS.
I checked it.
Such folders seemed to disappear from TFS, and I thought the problem was solved.
However, after that, when I GLV on the same machine, then Clean, then Build, then check-in recursively from the root of the TFS workspace, TFS automatically adds the dll’s and other extension like .cache files in those folders back into TFS! And we are back to square one.
So, should I try to prevent such files being checked in, or is there a way for all those files to be stored inside TFS without then causing me compilation errors??
Also, if best practice is to avoid checking in the bin and obj folders, how to I check in recursively from my local drive, after building, without checking in the bin and obj folders? Is there a way to exclude certain folder or file types?
Add a .tfignore file to the repo root so that those folders are not tracked by source control.
bin
obj
should be enough.
In a project I'm working on we check in Ruby with sass in order to compile scss files during the build. I switched to using a local workspace when updating gems so that changes are detected automatically. This works great except for the fact that files for new gems that reside in a bin folder are always ignored.
I have no existing tfignore files so I wonder is there some global ignore list that I could potentially edit or override.
I've tried adding a tfignore file at the root and even at the same level as the bin folder in an effort to force team explorer to stop ignoring those files but have had zero success thus far.
The content of the tfignore file is just one line:
!bin
How can I get team explorer to detect these changes automatically so I don't have to go through the extra step of finding and adding these files manually?
Bin and Obj folders are never shown in the project and adding files within those directories require some kind of manual step. If your goal by "not adding them manually" means you don't want to add them through "Source Control Explorer" but would just rather add them while working with a solution and project through "Solution Explorer", then you can click the "Show All Files" icon at the top of VS 2013/2012/2010.
This will then show you your potential bin/obj folders you may want to add files from:
Then you just right-click and include them. Once they're included, when you go to check them in, TFS knows you intend to add them to source control so it will show up in the Team Explorer pending changes window, if you are checking in from a higher-level in tree hierarchy. If you're not, then you can go to the "Excluded Changes" to find pending change you want to include in your final change.
If items are being excluded in anyway, try removing the .tfignore files and depending on your version of Visual Studio and settings, you may also be excluding your files through options such as this:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\AddOptions
Over the last several months myself and those on my development team have run across a new issue. When TFS creates a folder or does a 'Get latest' and overwrites any of the files in the folder structure, it changes the folder permissions to 'Read-only'. This causes an issue, an inconvenience really, where when we go to build the project it will tell us that our access to those folders is denied. If we open the folder and un-check 'Read-only' we are then able to proceed with the build and/or publish of the solution.
We have checked with our networking department, this is not a network setting and is not occurring anywhere outside of TFS. This is only occuring when TFS creates the folder.
Is anyone else having this issue? I've been pouring over settings off and on, trying to determine if I can change this setting. I do not want the folder to be read-only when it is generated or updated.
This is by design but your inconvenience is not. In TFS 2012 (with VS2012) Microsoft introduced local workspaces that do not put anything as readonly.
You can go to the settings of your workspace and change it from server to local any time.
You are also making a common mistake in that you have files that change during a build under source control. If you remove those files you will be able to build even with server workspace.
It is bag practice to put files that you generate under source control.
Just started up Visual Studio 2012 and opened my solution which is in source control with Team Foundation Server 2012 Express and encountered this, any ideas? Can't get latest, can't check in, everything appears checked out :( Basically my workspace is unusable right now.
TF400018: The local version table for the local workspace MY-PC;My
User could not be opened. The workspace version table contains an
unknown schema version.
There is only one post I could find on the net, and the answers are pretty vague.
I had the same issue, and I just fixed it on mine.
If you don't mind re-map all your projects, you can try follow:
Click the box in "Workspace".
Click on "Workspaces".
Delete the workspace profile you're currently using
Re-connect to TFS open "Source Control"
Be aware that you may lose all your TFS mappings, you may need to re-map all your projects from TFS. Backup your changes that not checked in yet.
cycle6 is correct, but it isn't clear that you will not lose your pending check-in list if you follow some additional steps.
Click the box labelled "Workspace".
Click on "Workspaces".
Delete the corrupt workspace profile, accepting the warning.
Re-connect to TFS and open "Source Control Explorer"
Create a new workspace
One by one, map your projects to the same folder as before
You will be presented with a list of conflicts, where you have matching writable files in the folder already.
Choose "Keep local copy" for each file you had checked out before, and "Take Server Version" for any files changed by other members of the team that you didn't have the latest version for. This might take a while depending on the length of the list, but it is worth comparing versions for any file you are unsure of.
You will be left with your solution and all pending items marked as checked out, with your work preserved.
I did the following steps and it solved the issue:
deleted the hidden folder named $tfs and then
in the Visual Studio, Solution Explorer: Right click on the solution node > the Source Control > Get Specific version > latest version
If you already have multiple instances of Visual Studio open.
Close all of them . [in some cases you need to log out from windows & log back in OR restart ]
Rename the $tf folder with any other name (eg. $tft)
Start Visual Studio, to see your issue fixed. :)
Hope this helps.
Sometimes this happens when you are running out of disk space.
Try to see if you have very low space, eg. < 10 MB.
If that so, try to clean up your windows Temp folder. See if that solve this issue
It's a misleading message to an extent.
What has happened is that the internal data structures of the workspace have become corrupt.
The ends up as the code (in the tf command, Visual Studio, et al.) to load those data structures failing to load from the relevant files, which becomes an error about a schema version problem.
In the case that I experienced, this was because the machine hosting the workspace ran out of disc space while doing operations upon the workspace of various kinds (check-outs, check-ins, adding pending changes — it was actually a bunch of workspaces being used by TFS 2017 build agents and multiple active builds).
This corrupted parts of the data that are held in the files under the hidden $tf subdirectory (it always being a local workspace on a TFS 2017 build agent), because source control wasn't able to rewrite/extend these files.
Other answers here discuss partly retaining some of the files, based upon more specific knowledge of what has not been corrupted (such as preserving the internal files storing pending changes if one wasn't creating any pending changes), but the basic idea is that one needs to reset all of the stuff in $tf to a sane state of some kind.
In my case, I had the disadvantage of multiple potential causes and no consistent knowledge of which parts of $tf were corrupted, but I conversely had some advantages:
It being a TFS build, arranged to build from the build agent's s (source) directory into its a (artifact staging) and b (binaries) directories, there were not masses of non-source-controlled object and other files in the workspace (which is the s directory) that would have ended up as pending additions.
There were not any pending changes (to actual source files) worthwhile to preserve. I could afford to lose all information about source files, and indeed all current locally-stored information about the workspace, and simply run the build again with a fresh sane and largely unpopulated workspace. I did not even need to restore source files and directories for the whole workspace, as the first task in any TFS ("vNext") build is a "Get Sources" task that uses (variously) tf vc scorch, tf vc undo, and tf vc get to check out the right source version.
So simply, in Developer PowerShell (Visual Studio being installed on the build machine):
Remove-Item -Recurse -Force 'X:\Agents\07\_work\1138\s'
tf vc get 'X:\Agents\07\_work\1138\s'
(Note that one can always get at the tf command in some way on a TFS build machine. Every build agent has a local helper copy of tf.exe and its ancillary DLLs in its VSTS "OM" subdirectory.)
I possibly could have omitted the tf vc get step, but having had trouble with "Get Sources" in the past I do not trust it to robustly cope with arbitrary manual external alterations, such as no s directory when the build isn't configured to outright delete that entire directory itself (as it can be but was not here).
For the same reason, Microsoft's own "agent maintenance" (another way to clean things up) is quite dodgy, and ends up leaking workspaces on the TFS server (which I have raised a bug with Microsoft about).
There is simple workaround. Remove local mapping to folder where is the sources (Advanced -> Remove Mapping, or just rename or delete mapped folder. After that you will be able to connect to tfs. Download the project again.
If you already have multiple tfs instances of Visual Studio open.
1.) Open File -> Source Control -> Manage Workspaces
2.) Delete all tfs map
3.) Then select folder maps
For the same issue in eclipse: Find the folder $tf and delete it.
You will find the $tf folder in the workspace directory. If not then search for the $tf folder.
Once you have found it, delete it.
In my case, none of the other answers helped - the problem was occurring on a machine that didn't have Visual Studio and no matter how I tried to get rid of the bad workspace data it never worked. After working with procmon a bit, I discovered another critical folder that might be the source of this error: C:\Users\All Users\Microsoft Team Foundation Local Workspaces\ (it might also be under C:\ProgramData (on my system, 'All Users' is a symlink to that folder, but not sure if this is typical.) In this folder there are sub-folders named like guids that contain some other folders, one per workspace it appears. In my case, some of the data in these folders was old and some was corrupt. Once I deleted the bad workspace folders, all my problems disappeared. You might also want to delete the Cache folder as identified in the comments of this post, but that didn't help me (didn't seem to hurt though, either.)
Alternatively, you could just backup your current workspace to a different location, re-create your workspace, and copy the files back that you had made changed to. VS should detect the newest files and automatically check out these files allowing you to check in the newer versions that you copied back from your backup.
What worked for me is, delete the local folder(s), restart your machine, then map the projects again. Any pending changes you have just save them somewhere else temporarily.
Scenario:
A solution is checked into TFS. Changes are made to an offline/disconnected/unbound copy of the solution, which becomes "the latest" version. I want to update the repo with this disconnected copy's files.
How do I get TFS to look at all the files and determine which ones have changed, so it can check only those in?
If this were SVN, I would just plop the files on top of the existing working copy, and it would just work.
Do you have another copy of the solution that is bound to TFS? If not, you'll need one. You have two options:
Take the solution "offline" by right-clicking on the solution node and click "Go Offline". You can then copy your changed solution on top of the bound solution. When you load the solution again, right-click the solution again and choose Go Online. This will scan the disk and determine what has changed.
You other options is to run "tf edit" recursively on a bound solution, copy your changed solution on top of the bound one and then run "tfpt uu". "uu" stands for undo unchanged and it will undo changes to the files that are not different.
I cant think of any elegant way off hand but your best option would be to know what files were changed or added offline and connect them to the TFS version while removing the old TFS files.
To do this simply right click all of the old files and either delete them or exclude them from the project then move the new files into their physical folders and replace them with the updated version. If files were added then add them in the correct folders. Finally make sure all files are view-able in the solution explorer by clicking "show all files". Finally, right click the files you changed and select include in project for each.
This way you will have replaced only the files that were changed and won't have to check in the entire solution to TFS making it very unclear what files were changed with your check-in.