I got my project from TFS but for some reason the second time I tried to open it, it said that my bindings were invalid. I haven't changed any file names. I looked up the issue and tried to undo and redo the bindings by going to source control > advanced > change source control, but after I unbind my solution, when I click 'bind' it just immediately says it's invalid again.
I hate to suggest this, but I would start from deleting the workspace and download solution from source control again. If this does not work, can you post your workspace mappings and solution structure - does it include websites?
Related
I'm switching to a new machine and would like to keep my TF files as they are. Thus I simply copied the entire folder to the new machine's (same as the previous one - C:\TF), mapped it to the TF server's root, and attempted to open a solution from the file explorer, hoping that it would bind more or less automatically.
I then ran into issues similar to others that have been described elsewhere, such as here and here. VS/TF insist that the binding on the solution and all projects is "invalid".
Unbinding and re-binding does not work, the binding reappears but remains invalid.
Recreating the workspace does not work.
There is nothing funny about the solution file's content.
The relative paths are correct - if I remove the bindings and try to add the files to source control, it overwrites the already existing files in the source control explorer (the item previously appearing as a grayed-out "Not Downloaded" becomes white with an "add" pending change).
Tried mapping the workspace to a "fake" network drive that pointed to the new machine's hard drive (just in case TF was mixing up the identical paths), still the same.
Deleting Team Foundation's AppData settings doesn't work.
When I perform a get on the solution folder, though, the binding becomes healthy all of a sudden. In the end I performed the get, deleted all the new files and put the ones from the old machine in their place. VS/TF apparently had no issues with the binding then. It's a rather inconvenient way of achieving that end, though.
I'm forced to conclude that TF doesn't want me to bind my own, local files to source control without first performing a get in that workspace, even if the file paths match what is on the server. Question: why is that? Am I doing something conceptually wrong? Doing it the wrong way? Is this behavior an idiot-proof feature of the tool, or just a limitation?
You're doing it wrong :/. | it's a feature, not a bug.
The workspace is registered on the VSTS/TFS server as well as in the local workspace cache. After moving the folders over to a new machine (and to the same folder location), you need to tell VSTS/TFS the new computer name these files now reside on.
You have to run tf vc workspaces /updateComputerName:oldComputerName workspacename to update the workspace registration on the server.
But I'm afraid you need to do this before overwriting the workspace with a new mapping.
Now I think the only option is to use the Unbind option, save all, then open the source control menu again and rebind all the projects in the solution. Or edit the solution files manually (there's a tool for it as well).
I have a situation where a developer made mass changes to a project outside of TFS (long story), and now we want to put those changes back into TFS (files added, removed, renamed).
Of course, TFS is not like Git; if I check out the project, then delete the files from the workspace and copy over the new files, TFS won't adapt to those changes.
I have discovered that I can do a Compare from File - Source Control, and that the Compare screen allows me to mark files as added/deleted. This helps, but is a slow process for a large project, and quite prone to human error.
So, my question is: Is there an automated way to get TFS to simply add all new files and remove all deleted ones?
I don't care about tracking history of renamed files--they can be
considered "removes" and "adds."
I have tried unbinding and rebinding the workspace; this did not work for me (or I didn't do it correctly).
I am using VS 2015, TFS 2015, and I have the TFS Power Tools.
If you are using a Local Workspace then you should be able to get latest on the workspace, then copy over all the new files in Windows Explorer which will generate pending changes and file adds.
If you go into Pending Changes in Team Explorer you will have lots of detected changes for new files etc. but you can promote them to included changes.
This isn't going to deal with file renames or deletions though so it might not be the best solution.
Alternatively you could use Reconcile Changes in Version Control
In Source Control Explorer, right-click a folder, and then click Compare.
In the Compare dialog box. select the folder versions to compare.
In the Folder Difference window, right-click the folder or file you want to reconcile, and click Reconcile.
This will allow you to choose what to add or change to version control
You might try using tfpt online. I would add the /adds /deletes /diff /recursive flags as well.
I think in almost any case you will have some conflicts/manual work to do here.
There is a blog post on a possibly similar situation that used tfpt online as well: Discover File Changes Made Outside of Visual Studio
Since I did not get to try the above suggestions, I'll post the workaround I did, in case it helps anybody else. Hopefully, the above suggestions are better than what I ended up doing.
Make sure nothing is checked out
Open solution
Team - Go Offline
Close solution
Windows Explorer - Copy latest source folder into the current source folder (Windows Explorer will do a Merge).
VS - Open solutin, select solution file
File - Source Control - Advanced - Change Source Control
if you get a message about unloaded projects, make sure all projects loaded. Click "Reload" on those that didn't.
Shift to select all project, click Bind
Do a Compare in Source Control Explorer. Manually add all new files. Manually delete all deleted files. Frown.
Had to change my computername and domain. Now I can't access team foundation. I tried this statement to fix it.
tf workspaces /updateComputerName:MyOldComputerName /s:"http://MyServer/MyCollection"
It didn't work. I get the following error "Key not valid for use in specified state."
Not sure what to do now.
It sounds like you may have a problem that will prevent remapping the workspace. However, it's possible that the command isn't quite correctly formed, so try checking the collection URL (I'd expect it to include MyServer:8080), and in versions of TFS 2010 onwards the documentation refers to /collection: rather than /s:
If that fails, then one approach to rescue things is to create a new workspace and delete the old one. You can transfer any edited files you had checked out to the new workspace as follows:
Rename your old source code folder, so you keep a backup
Create a new workspace that maps the (old) source code folder location, and Get the latest version of the code.
If you think you deleted or added files, use a folder-diff utility to find them, and manually re-do those changes.
Now check out everything (right click on the root folder and check it out)
Copy your backed up source code over your workspace folder
Undo checkout on everything. Visual Studio will ask if you want to discard your changes. Carefully choose the "No to all" option. This means it will only discard locks on unchanged files.
You will now have all changed files listed in your pending changes.
Once you're absolutely sure this has all worked, you can delete your backup of the source.
(You can achieve a similar thing by unplugging your network cable to force Visual Studio to go offline, moving your old source code back in place of your new workspace folder, then plug the net cable back in and using File > Source Control > Go Online. This should diff your code to the server and work out what changed. I don't trust this as much as the above approach though)
Once you have the code in your new workspace, you can use the tf command to delete the old workspace to clean everything up.
I'm relatively new to tfs so I did a mistake, I moved my (already under tfs) source code to another location (moved the solution folder to another destination), the problem is I have changed my source without checking-in my pending changes and now visual studio says that my "solution seems to be under source control but its binding information cannot be fond".
now how can I take my changes and apply it to the tfs(keep in mind that my solution is no longer under tfs binding)?
Start by restoring the binding of your solution with source control as described in: http://msdn.microsoft.com/en-us/library/ms181374(v=VS.100).aspx. If the source control system does not recognize that this solution has been moved after re-binding, add it as a new solution to source control and remove the old solution from source control.
Before performing any of these actions, always make sure you have a backup of the sources off-line.
i'm working with TFS and i need to edit file localy without checking it out .
another case if some one checked in the file and i need to change my locally copy.
what should I do ?
in Visual source safe we can do that by removing the read only check on the file.
Ok, this is relatively easy in VS2010, and quite normal. I mean the locking model of source control is obsolete anyway.
In vs2010, click Tools -> Options -> Source Control -> Environment and select Allow checked-in items to be edited. This should stop the TF client from marking files as read-only.
Also you may have to change the Editing drop-down in Source Control -> Environment to Do nothing.
Well.. You can certainly unmark the file as read only and edit it in something other than visual studio. Or, you can still use visual studio, but not edit it when the solution it's a part of is opened..
Quite frankly, I'd look into other options with regards to why
1. that file needs to be in source control.
2. If it does need to be in source control, why does your copy need to be different.
Just unset the read-only flag on the file locally.
You may have some issues later when try to do a "Get Latest" operation, which will warn you about a locally writeable file.