I'm currently working on a custom build process and have a problem with the understanding of drop folder. The process creates only some reports which we need for further development. We are using TFS/VS 2012.
What I actually need is either a folder on the buildserver where the Reports are going to be saved and accesable from everyone or on each team members local machine a drop folder. In my opinion the first solution should be better but is it possible, since I'm the only one out of my team which has Access to the buildserver.
If I select the UNC path to the drop folder on the buildserver can other People without Access to this Server use the "Open Drop Folder" button? And how do I even copy files to the drop folder? Is it enough to just do CopyDirectory? In the moment it always says: "This build did not produce any Outputs. The drop Location field is empty..."
I would be really glad if someone could help me.
The purpose of the drop folder is to copy the result of the build from the working folder of the agent and somewhere where it will not be changed by a later build. The share can be on the build server or on another server. No matter what you need to control the permissions to that folder so that whomever needs access has it. Otherwise the Open Drop Folder button will not work.
You can enable so that the build results are copied to the drop location upon build completion. This is a bit different whether you use Build vNext or XAML build. Since you are using TFS 2012, I guess that you are using XAML builds. Drop location is specified under the Build Defaults tab of the build definition.
The output folder from your build will be copied so assemblies, test results etc. will be copied to the drop location when enabled. If there is something extra that you want to be included in your drop, then copy it to the output folder or create it there directly.
I am developer and work with TFS for a while but never have the responsibility of TFS admin. We have a user that was let go and now his userId has been revoked so we cannot use his id anymore.
He has so many files checked out in TFS and a lot of stuff done, we don't want to lose these checked out files if possible. Is there a way to transfer all his checked out files to me or someone else? Or what is the best way to recover these files?
NOTE: we still have his laptop with all the files, we just cant login to it with his username.
Thank you for your help in advanced
Download TFS Sidekicks (get the right version for your TFS)
They have a Visual Studio Add-in if that is what you are using as your IDE
Backup his files that you want to keep
Use the Workspace Sidekick of TFS Sidekicks to delete his workspace(s)
(this won't delete his files).
This will release any exclusive locks that he has effectively undoing all his checkouts.
You can also use the Status Sidekick to see what files he has checked out.
Get latest source and copy his files over yours
If you are using TFS2012 or later, you can use a 'local' workspace and simply copy his files over. Team Explorer will create your pending changes for you. If you are using a 'server' workspace or a version of TFS prior to 2012, you will need to full check-out everything and THEN copy his files over.
It's not a great solution but it should work for you
The changes to the developer's files that are checked out will be stored locally on the developers machine (specifically in their workspace directories) - transferring "check out status" would seemingly not accomplish what you hope.
You would need to obtain access to the developer's workspace (perhaps via an admin account on the dev's machine), copy out all the contents to a new workspace you own to consolidate differences between "source" and "new workspace".
Once you've copied the developer's workspace to a new workspace you own, you can simply compare "source" to "workspace" to find all the changed files and which are needed vs. not needed. Note, this should be done sooner rather than later as the longer you wait the more differences there will be between the two, making it harder to identify what is actually needed.
using VS 2012 and TFS, and I cannot exclude the packages and bin folders from the check-in process, unless I manually exclude them every time. I have created a tfignore file using the VS interface which specifies folders and also file types (e.g. *.nupkg, *.dll etc) but it doesn't work. They still appear in the Team Explorer check in process, and it's causing problems. Please help, it's really annoying me.
is your workspace a local or server one? .tfignore works only on local workspaces.
Have you checked existing SO threads, e.g. How to ignore files/directories in TFS for avoiding them to go to central source repository?
If the problem still exists please describe exactly how you add files to tfs (pend add)
I have referred to a lot of forums and also this so question but my problem is that I have formatted my machine. So I'm not able to overcome this issue. I have tried deleting workspaces from visual studio command prompt and also clearing cache, but I feel this mapping is more on the server-side than local cache, because my machine was formatted. I don't know which file has this old working path saved.
Also I have tried downloading the project into a new working path. I was able to download, but then I don't get the TFS icon against each file. i.e.it's like working offline (disjoint from TFS database). On right click we generally have an option to return online or go online. In this case on right click I get TEAM -> Apply Patch & TEAM -> Share Project
Please help me with this.I had the same problem in my asp.net projects, when I simply downloaded them onto a new working path it worked fine. But this java project in eclipse just doesn't seem to connect to tfs when downloaded into a new path nor does it allow to download in the old path.
Please not I have formatted the machine.So my case is different, so this may not be a possible duplicate of other SO questions.
I did not disconnect or delete workspace before a format(due to lack of knowledge) at that point. May be doing that would never cause this.
All I did is check in all files and re-formatted my windows.
I'd suggest using the (free) tool TFS Sidekicks: http://www.attrice.info/cm/tfs/
This will give you a GUI to view all workspaces (across all users and machines), and delete the obsolete ones.
This is stored on the server, but the tf workspace command should be able to remove it for you. You will probably need to supply it with the correct machine name to find it:
tf workspaces /computer:* /owner:domain\jesse.houwing /collection:http://yourserver:8080/tfs/DefaultCollection
Find the missing workspace (the one that was formatted) and remove it from the server:
tf workspace /delete /collection:http://yourserver:8080/tfs/DefaultCollection workspaceName;domain\jesse.houwing
Do not confuse tf workspaces /remove and tf workspace /delete, the former only removes the registration from your machine, the second removes it from the server.
Or, if the computer name and the username have stayed the same, edit the workspace and delete the paths no longer valid (or update them to their new location) by changing the workspace configuration. Use
tf workspace workspaceName;Owner
to open the dialog to edit your current workspace.
Or use
tf workspaces /updateComputerName /updateUserName
To reassign the workspace from the old computer (iinstallation) or user to the new one.
I tried using the TFS sidekick tool, but even then, ran into access denied error. Then I had to manually clear off the files from this path:
C:\ProgramData\Microsoft Team Foundation Local Workspaces
So this can be alternative, if you do not want to install a tool or your company does not allow you to install software from unknown sources on your laptops due to policies.
This already has a marked answer but my problem was solved without command line or additional software.
I had just recently updated to '15 and I was migrating my workspace folder to another drive as it was getting too big. The error being uninformative as it was, still appeared even after I deleted the workspace it cited...or so i thought. Both VS'13 and '15 by default made the same named workspace but one for each version. I had to reopen '13, and delete that workspace then move back to '15 where it would now let me remap my folder.
Hope this helps someone.
logout from previous user and login by new user.
Copy Project Folder to Another path.
In team Explorer Right click on project and Remove mapping.
Remap Project
go to Control Panel --> User Accounts --> Manage your credentials --> Edit tfs User Name
user name : your TFS user.
I solved it like this.
I had the same problem.
TFS workspace manager throw me this error:
"The working folder \PATH\ is already in use by the workspace my_computer_name name_of_previous_user on computer my_computer_name"
I solved this problem by creating user in TFS server and deleting the previous one.
U can go to TEAM> TEAM PROJECT SETTINGS > SECURITY.
& if u have permission- create your own user.
This is what I did to get it to work using Manage Workspaces in VS:
Click on Show remote workspaces, delete remote workspaces as I was not using them anyway, not sure if this was needed.
Created a new Workspace B and mapped to another folder Y and choose yes to download all files now.
Deleted original workspace A, mapped to Folder X.
Recreate original workspace A and remap to folder Y (wrong folder) and choose Yes to download all files now.
Delete Workspace B
Edit Workspace A, go to Advanced. At the bottom where it says Wroking Folders, change the Local Folder path back to folder X and choose yes to download all files now.
Not sure if you have to do all those steps but that is what I did to finally get this remapped, only took all day.
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.