We moved to a new tfs, with a new name, the old one doesn't exist anymore.
When I create a new blank solution and select file|source control|change source control and click on 'Bind' Visual Studio tries to connect to the old tfs.
Under Team|Connect to tfs|.servers I removed the old one and connected to the new one only.
Also my workspace is mapped to the new server only.
I cannot understand where Visual Studio stores the old tfs or how to destroy it's memory.
You may have to delete your workspace as explained here
http://blogs.msdn.com/b/buckh/archive/2006/09/12/path-is-already-mapped-in-workspace.aspx
Related
When I open Visual Studio and attempt to connect to TFS, I get the following error message:
Error
Unexpected end of file.
I've found a handful of places online (like here and here) where people have run into similar situations but clearing the Team Foundation cache as recommended doesn't solve the issue.
I even completely uninstalled Visual Studio Enterprise 2015 and installed Visual Studio Enterprise 2017 and still get the same error.
I recently created a new TFS instance on another server for testing out some automated build features without messing with our current setup and can connect to the new TFS instance just fine.
What would cause this error?
First you could use another machine with VS installed to connect the same TFS under your account. This will narrow down if the issue only occurs on your local machine or not.
You could try to clear both TFS and VS cache issue.(You may not uninstalled the previous VS clearly).
For TFS cache:
close all instances of Visual Studio on the client machine,
manually delete the corresponding Tfs client cache folder, and then
start Visual Studio
The corresponding Tfs folders to manually delete are as follows:
Tfs 2017: "%localappdata%\Microsoft\Team Foundation\7.0\Cache\"
Tfs 2015: "%localappdata%\Microsoft\Team Foundation\6.0\Cache\"
For VS cache:
Delete the contents from the following folders
C:\Users\<<Your Alias>>\AppData\Local\Microsoft\VisualStudio
C:\Users\<<Your Alias>>\AppData\Local\Microsoft\VSCommon
Moreover, also give a try with removing the tfs related credentials from Credential Manager, close all Visual Studio instances, deleting %LOCALAPPDATA%\.IdentityService, use another user account connect to the TFS server.
Update: Op ended up doing an OS reload and haven't had any issues since.
I ended up doing a full OS reload
It was likely overkill as I'm convinced there was a cached file somewhere I couldn't locate that was holding those settings but I didn't have the extra time to fiddle with it and I needed to move to Windows 10 at some point anyway.
I'd venture to guess #PatrickLu-MSFT's answer will work for most people but for whatever reason it didn't for me.
In my case I closed Visual Studio 2017, went to the solution's directory and deleted the .vssscc file.
The file was then regenerated and the problem was solved.
I am getting the aforementioned error most times I unshelve from Team Explorer > Shelveset Details, but unlike this question, I have my workspace set correctly under my Pending Changes window. The weird part is that I am always able to unshelve after trying a second time without changing anything.
It didn't always do this to me, and it seems to not affect anybody else on my team. I've not messed with any settings that I can think of as being relevant either.
And yes, I've restarted my computer since it started happening.
Another thing it does is deletes all ADD changes upon reconciling after passing a gated check-in build.
Thanks.
Using VS 2015 Update 3 (version 14.0.25431.01) connected to TFS 2015 (version 14.102.25423.0)
According to your description:" it seems to not affect anybody else on my team". The issue should be a client side issue.
First,you could use another TFS account to unshelve Shelvesets on your develop machine. This will narrow down if the issue related your account or not.
Suggest you try to clear TFS and VS cache:
For TFS cache:
close all instances of Visual Studio on the client machine,
manually delete the corresponding Tfs client cache folder, and then
start Visual Studio
The corresponding Tfs folders to manually delete are as follows:
Tfs 2015: "%localappdata%\Microsoft\Team Foundation\6.0\Cache\"
For VS cache:
Delete the contents from the following folders
C:\Users\<<Your Alias>>\AppData\Local\Microsoft\VisualStudio
C:\Users\<<Your Alias>>\AppData\Local\Microsoft\VSCommon
If above not work, you could also delete the old workspace(back up local changes first), and create a new one. Then test it again, which should do the trick.
It turns out that opening the shelfset before changing my workspace from pending changes causes the issue. The solution is the change the workspace in pending changes before opening the shelfset.
I'd definitely call this a bug in VS since the shelfset viewer does not indicate which workspace it is referencing before unshelving.
We have migrated TFS from one server to another. I have verified that the source files and history do exist in the new server location.
How do I now redirect Visual Studio to look at the new server location? I would like to not lose any of the files, history and to realize pending changes, etc.
TIA
You have to connect to the new TFS from Team, Connect to Team Foundation Server menu.
I got a project which includes both a windows service (a C# project/solution in VS2013) and some SQL scripts (a SQL Server Script project/solution in SSMS 2012).
Both of these use TFS as source control.
The strange thing is that pending changes differ between VS and SSMS.
In SSMS I only see changes to files in the SSMS solution.
In VS I see all changes in both solutions except new files added to the SSMS solution.
This means I can't check in all changes in one place and have them in one change set (unless I manually add the new SSMS files in the VS Source Control Explorer).
I am pretty new to TFS (coming from Mercurial/Git) so I still don't understand how many things work, e.g. how pending changes/source control explorer detect new files.
If you are using TFS 2012 or later, you can choose either a local or server workspace from within VS. There are pros and cons to each but with the local workspace you should be able to achieve this requirement. Visual Studio will detect new files that is within it's source control and add/edit/delete as a pending change as required.
What version of TFS are you using?
I'm facing a strange problem: I have a new installation of TFS 2010 on a test machine and I use Visual Studio 2010 Professional on a client machine. My client was before configured to be connected with another TFS 2010 machine with the same bindings. Now, from my client machine I manage to create Team projects in the default collection, but nothing is happening when I try to add a solution to source control. It means that when I physically push the button "Add solution to source control" no window or message is showing.
Of course I set all the permissions and group memberships on the server machine, and I restarted client and server several times.
How can I solve (or at least make a diagnosys) the problem?
Have you also removed the workspace from the old TFS? Workspace mappings cannot be shared across multiple TFS instances.
Do you have Team Explorer installed? Is TFS set as the default source control provider in Tools -> Options -> Source Control -> Current source control plug-in?