A colleague and I are working on the same area of code using Visual Studio 2008 and TFS 2005 on the server.
When we both edit the same file concurrently and I check it in first, TFS does not recognise this when he either gets latest version or checks in, meaning his or my changes get overwritten without a painstaking manual merge.
This only seems to be a problem for him.
Any ideas what the problem might be or how we can fix it?
We removed and recreated the workspace and that fixed it. Job done.
Related
I am using Visual Studio 2017 (15.9.8) with an on-premise installation of TFS 2017.
In our team a checkin is required to have some associated work item. This worked fine and does still with all of my colleagues.
But when I do a checkin, I get the error message (see title) with every work item I associate. Since checkin works fine, it is just annoying to associate the change sets manually.
I do not use any custom code, so I can't debug any API (as suggested by Shayki Abramczyk) - it's just a matter between VS and TFS. I tried to intercept the communication between VS and TFS, but that did not work yet.
How can I find out which fields are invalid? Is there any type of log where I can research the cause?
Guenter
After much unsuccessful attempts the following command made my day:
witadmin rebuildcache
It seems the cache had been corrupted by using a TFS production dump as a test environment. After clearing the cache everything works fine again.
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're working with a solution which has multiple projects which references NuGet packages from other solutions.
Every time we do get latest from the TFS server on the solution, Visual Studio (2015) starts reloading each project in the solution which takes a really long time. Now this wasn't always the case, since this started happening only a few weeks back (the solution is a year old).
We have other solutions which were already experiencing this problem and our solution is to close the solution, then do get latest, then reload the project which is much, much faster.
Can anybody explain why this is happening and how to fix this issue?
This has been reported as a bug to MSFT, see Slow project reloading & Reload of projects is slow after call to TFS to get latest changeset. It seems your project files are updated from outside VS, which causes VS to load all them. More details please see the reply from VS IDE team:
Main culprit is, your project files are being updated from outside
VS, which causes VS to load each of them one by one. This is
extremely taxing process and it happens on the main UI thread. Hence,
this ASL logic is on-by-default to alleviate unresponsive solution
loads. Essentially, you’re pointing out a limitation in our ASL logic
that we hadn’t considered. This will be considered for a future
release, thank you.
In the meantime, one way to mitigate the problem would be to force
solution reload by touching the solution file, the *.sln file, which
will trigger ASL to kick in, basically VS thinking you’re doing full
solution load and it will optimize responsiveness time as much as
possible.
Ulzii Luvsanbat
Visual Studio IDE Team
Please try these steps:
Open Visual Studio installer and install the most recent available update for 2017 version.
Open %localappdata%/Microsoft/Team Foundation/7.0/cache and delete all files, then restart Visual Studio and retry.
In my Visual Studio 2013 I'm trying to get the latest version of a project from TFS but this hangs on until the timeout error occurs.
I've tried deleting the Team Explorer cache a couple of times, undo all the changes, restart, rebuild but still the same issue.
What's even more interesting is that there someone else in my team with a similar version of Visual Studio that hangs when getting the latest on the same project.
We're using VSO so I was expecting this will not have issues.
Any ideas?
Thanks,
Andrei
Please make sure if you are running antivirus that your work space is excluded from the rules. Otherwise it has to check each and every file which is a major slow down. Also check your local work space to see if the files are getting copied. Check the event log on the TFS server it may have a reason. Also try using the VS command line to make the same request.
I have:
Visual Studio 2010 Premium Version 10.0.40219.1 SP1Rel
Resharper 6.1
One other minor Extension I got off of Extension Manager
The team is using Team Foundation Server 2010.
I haven't been able to figure exactly what things triggers this, but I constantly have to re-set my solution Startup Project configuration. I think it's whenever I restart my computer and after some "Get Latest" retrievals. Here's a screenshot of the source directory structure in Source Control Explorer (not Solution Explorer):
Any ideas why I would have to re-set those properties sometimes?
This setting 'lives' in the *.suo file. It is certainly wrong to insert this file into Source Control. In the picture you 're providing, there doesn't seem to exist one - but keep in mind that's a hidden file: so it makes sense to check if you actually have one checked in along with your other sources.If yes, it absolutely makes sense that this gets changed with every GetLatest & you should probably remove it from your repository.If not, having this issue only makes sense when you map your source every time in a clean folder like #leppie says.Check also here & here for similar posts.
EDIT
OP commented below that his *.suo file was in fact not checked in - so the above passage is not really helpful. Another SO post seems to have been the case instead. Following the instructions there, OP got his issue resolved.