I have multiple solutions that were previously mapped to a hosted TFS. Their local mapping was defined as well and all the source code was up-to-date locally. I have since discontinued my TFS subscription and started using visualstudio.com as my TFS server.
I went into one of the solutions, deleted the *.vssscc files from the solution and the *.vspscc files from each nested project. When I open the solution in VS 2013, the output window gives me a message saying the the original TFS (unsubscribed now) is not available and that the solution is open offline.
As a result, when I choose the "Change source Control" option, it first asks me to log in to the old TFS whose credentials are no longer valid.
Furthermore, it tells me that the local directory I am trying to map to the new TFS is already mapped to the old TFS. How can I remove this mapping without having access to the old TFS?
Not sure if this works if you're offline, but you can remove the mapping by opening the Manage Workspaces area in Source Control Explorer (click on the ... option of the dropdown to the right of Workspace:)
Manage Workspaces -> Select your workspace -> Edit -> Remove or change your mapping.
It's probably easiest to remove the mappings using the commandline
tf workspaces /remove workspacename;owner /collection:http://urlto.old:8080/tfs/ProjectCollection
After removing the old workspace configuration for the current folder and mapping the folder to your new subscription, Visual Studio should prompt you to automatically update the solution bindings to the new server.
This will not delete your workspace from the server (which keeps track of the workspaces), but since you no longer have access to it, it should be enough to let your client forget the folder is mapped.
The answers here work when the old TFS server is available. Mine wasn't but has not been removed from the server list in VS. Removing that entry allowed me to remove the solution from source control entirely along with the mapping and add it to another source control server.
Related
I have a couple of ASP.NET Core based projects being developed using Visual Studio 2019.
I am having issues where my workspace and TFS server on Azure-DevOps are out of sync. My PC contains the most recent code and I want to push everything I have on the server. I don't really care about the status of the TFS server as it is wrong. I just want to force everything to get pushed to ensure my PC and TFS are syncing again.
How can I force the TFS on Azure-DevOps to take all my files? I don't even mind removing the project altogether from Azure-DevOps and push all files as if this is a new project.
According to your description, sounds like there is something wrong with your source control binding. Or maybe some files outside of Visual Studio do not detect by TFS server. Which cause your workspace and TFS server out of sync.
If you want TFS server detect changes done to files outside of Visual Studio, the simplest way is using local workspace.
Now anything else changes files outside Visual Studio, your workspace detects the changes automatically.
It also detects adds or deletes but you have to include them to your Pending Changes manually with the link under `Excluded Changes
If you are using server workspace, this is kind like when you are offline, you cannot work with your local files because they are read-only until you check them out. So highly recommend you switch to local workspace, you just need to make sure you open the files in VS from a path which the same as your TFS local worksapce. Then it will auto sync changes in Visual Studio and show in pending changes.
More detailed information on the pros and cons of local and server workspaces, please refer our official link.
Now in your situation, we suggest you fist back up all of your local codes/files first. Then delete your old workspace, create a new local workspace.
Get latest from your sever, then copy all your back up to your workspace folder. Then let windows file system auto detect the difference between them, replace files download from server with your back up local version.
Now your local workspace should contain the latest version of your code/file, Visual Studio will auto detect the changes and list them in pending changes, if something added in excluded list, manually promote them.
Finally you could just check in/push all pending changes to TFS server. Now everything back to the track again.
Hope this helps.
Somehow on my team's TFS server, one of our projects got deleted. The code is on my local machine though so I'm trying to get it reuploaded, but I'm running into issues getting it back on the server. I've recreated the project and given it the same name and Visual Studio seems to recognize that the new project I've created is connected to the Project I'm trying to upload as a result. The problem is that when I try to check in the version I have to the new project it throws a pile of errors because the files "does not exist at the specified version or you do not have permission to access it". Is there some way to force the upload so that the files are all on the server again?
First remove .* folder from your current working project.
Then go to Visual Studio
Open Team Explorer
Click On Manage Connection
Add your account If not added
Enter your tfs url
Select your TFS folder where you want to checked in your code.
Try to checked in your code.
Even though you have deleted the project on server side, all changes in TFS are non-destructive.
You could check this, just navigate to the Source Control –> Visual Studio Team Foundation Server section.
In that section is a check box that says "Show deleted items in the Source Control Explorer"
If you have recreated the project and given it the same name and want check in local code to TFS. This may cause some trouble.
Suggest you to permanently destroy the project in TFS using Destroy Command (Team Foundation Version Control)
tf destroy [/keephistory] <itemspec1>[;<versionspec>][<itemspec2>...<itemspecN>]
[/stopat:<versionspec>] [/preview] [/startcleanup] [/noprompt] [/silent] [/login:username,[password]] [/collection:TeamProjectCollectionUrl]]
After destroy the old project, then create a new project with the same name, add your local code to this project, finally check in pending changes.
I have a folder in my workspace that insists on being mapped to a different location. I only mapped the root folder of my TFS project. The entire folder structure comes down to that location without exception when I get source... until today. I was troubleshooting the state of a web project and among other things, removed the entire solution folder (renamed to another location) and forced a get of the solution fresh from TFS. Now when I get latest, everything comes down correctly, but as soon as I open the solution, I get several messages that say Replacing (moved from ). One folder of the solution is moved and workspace working folder mapping shows up mapping that folder to the new location.
History:
My version of the web project had been upgraded from a website to a web app, and we needed to get it in a state consistent with the rest of the team. We removed some sites from IIS, deleted the solution directory, rebooted, and got the latest source code again. The website/web app problem was fixed, but now I have this persistent workspace change that acts like malware.
What I've tried so far:
Deleted TFS cache at Appdata\Local\Microsoft\Team Foundation
Deleted TFS temp files at Appdata\Local\Temp\TFSTemp
Removed the workspace mapping, deleted the solution folder again, restarted Visual Studio, got latest source again. The source is downloaded correctly, but when I run the solution, the working folders are mapped again, and the folder is moved again.
Checked the type of workspace. It is a server workspace (legacy).
Performed a Repair install on Visual Studio 2012.
Installed Visual Studio 2013.
Removed the workspace mapping and allowed Visual Studio to perform another get. This restores the solution structure, but the problem returns if I 1)Close and reopen the solution, or 2)Get latest on the solution (without forcing overwrite).
We did finally get a resolution for this in my case. Although I had asked the rest of the team if they had seen this behavior, and got no affirmative responses, when I investigated in detail, I found that many members of my team simply were not aware of their workspace much at all, and did not see that these mappings were being added. Not all members of my team had this issue. I believe everyone that was on a Server workspace did have the issue.
Once we realized that the problem was not unique to me, we found that the solution file was compromised. When we looked into the solution file (.sln) with a text editor, we could see the unwanted mappings represented there. We removed from the solution everything that was being remapped, and then added them back in. After double-checking that the unwanted mappings were no longer written in the solution file, we checked that in, and as each developer removed the added mappings, and then got latest again, the problem was resolved.
I'm having trouble setting TFS2012 to control project source files between 3-4 people.
I've been googling for 3 days, and now I'm completely lost trying to map local and server folders in workspace. So far I have managed to create a server, a project, and connect to it using Visual Studio 2010.
All I'm trying to achieve is to share one solution between this group of people, lock files for changing, and reflect those changes to server (and therefore to other people in my group) after I check in the file I made changes to...
Can someone explain how to set this up??
Workspaces are set up the clients, not the server.
So, in Visual Studio (including Team Explorer if you have only the TFS client without the rest of VS) connect to the TFS instance and select the right team project.
If VS does not immediately prompt you to create a workspace (it's been a while since I did this on a refresh install) go to File | Source Control | Advanced | Workspaces...
There you can select or create a workspace (remember workspaces are specific to the combination of user and computer). Once you open a workspace to edit you can create mappings between source control paths and local paths.
NB. in the workspaces dialogue you can select "Show Remote Workspaces" to see other users' and computers' workspaces and copy mappings to paste into another.
Recently I have been working on a project and have been waiting to publish it to Azure. Before I was able to do this my local user account on my machine was changed. Now when I try to add the project solution to the solution control explorer I get "access to path [old username]/my documents/projects is denied." I have the project copied from the old user account onto the new one I am using. I opened from this location, but it still seems to reference the old path. How do I change this and/or what settings do I need to change?
I have uploaded the project into the source control explorer for the project, and the rest of the team can view it. It is possible to re-load the project from here and create a new work space mapping on the new local account? If so how can I do this?
I managed to get it moved by doing the following, thanks jessehouwing for the push in the right direction.
Closed Visual Studio
Went to old account, copied project directly to the C drive
Went to the new account, opened the project from there
Deleted mapping referenced in the picture in jessehouwing's answer
Created new mapping under a different name, because even though the old one was removed, there was still a naming conflict (I have no clue)
Mapped the source control and local folder from scratch
You will have to change your workspace mapping. If the Source Control Explorer allows you, you can open the Workspace dropdown (in the toolbar) and edit the current mapping.
If the Source Control Explorer doesn't allow you due to Access Denied errors, you can also use the commandline utility tf.exe to remove them.
tf workspaces /remove
And then create a new one through the UI or also from the commandline using
tf workspace /new
tf workfold /map
I'm re-using an old picture here, step 4 should be to fix the paths in the Workspace folders list on the bottom of the dialog :).
This is still happening in 2022 and below are steps we have resolved this "Access Denied" in visual studio (2019 in our case) for Azure DevOps Server.
Open visual studio command line and run the command;
tf workspace /delete “WORKSPACE_NAME;OWNER”
Open folder C:\ProgramData\Microsoft Team Foundation Local Workspaces and delete anything folder inside
Verify C:\ProgramData\Microsoft Team Foundation Local Workspaces
folder has the user you are logged into the machine as full access
Go back into Visual Studio and reestablish your workspaces and
perform a get latest