Related
When I originally installed VS Ultimate 2013 everything was fine but for the last month or so it's been a dog.
The source control explore in my Visual Studio 2013 install is very slow. Just clicking on a node and the act of displaying the node contents takes 20+ seconds.
Everyone else on the team is ok so it's not the TFS server it's just my install.
I assumed it was some addin I'd installed into VS so disabled them but no luck.
Any ideas?
Having tried all suggestions, unloaded all add ons, tried to reinstall VS, removed all extra workspaces etc. the answer to my problem was to unmap my workspace and then remap it.
Problem solved. Not got a clue what the underlying fault was.
In my case, the only way to get rid of the lag was to change my workspace location from "local" to server. You can do this under the advanced options for your workspace.
The 'full blast' solution that worked for me was;
remove workspace
delete all source code
rebuild the workspace
rebuild solution
Only takes a few minutes more than just rebuilding the workspace (see #DaveF's answer) but gave me a bit more confidence that everything hangs together.
Had this happen to me a few times now, so there are some things I'd like to add to the accepted answer.
I work in a place where we have a lot of VS solutions with a lot of files in them. Microsoft's guidelines suggest that you shouldn't be using a local workspace if its going to have more than 100,000 items in it. So you could prevent this problem entirely by:
Not using local workspaces
Making sure never to map enough folders into a single workspace that it gets over 100,000 files associated with it.
Periodically declaring "TFS bankruptcy" and unmapping everything.
For me, the drawback of having to use strict locking and not having offline access makes #1 unacceptable. I'm going to try harder to do #2, but honestly #3 is what I've been living by.
Its kind of like early Windows, where every year or so you had to just reinstall the OS to remove all the accumulated cruft.
Cleaning local folders helped: See 'Team Explorer - Pending Changes', under 'Excluded Changes' it said: 'Detected: 50000 add(s)'. Click it to see path to folders.
This make me crazy too for over six months until I found this instruction. Now, my VSO is fling. Note: this information I copy from somebody. Would like to give them credit but I cannot remember how did I find this.
You can fix this problem of TFS by editing registry.
Navigate to key
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Proxy
and then change value of URL to any dummy website like 'www.abcdummy.com'
Restart VS after editing registry key value.
I had the same problem, it kept me busy for a week or so, but after investigating my complete setup i found the following:
Within my ASP.NET application, i had an image directory and an image cache directory, with lots of images in them. (+200.000). Both were not included in my VS project, but still Visual Studio / TFS tripped over this.
First i found, that when checking in some files (which took over 10 minutes when the problem existed), in 'Team Explorer - Pending Changes', under 'Excluded Changes' it said: 'Detected: 50000 add(s)'.
Trying to get rid of this the 'normal way', by opening that 'Promote Candidate Changes' window and setting these files to be ignored, still didn't do much.
But after moving those image directories to some other location, outside my project, all problems disappeared.
Of course i had to add those moved directories as virtual directories to still see my images.
I cleaned my workspace of unnecessary projects and it ran better. I think vh_click is on to something with the 50,000 ads thing. TFS keeps track of all your edits and over time with tons of projects, undos, and craziness you could amasse a large set of which TFS has to chug. Get out the Clorox, the Comet or whatever else you clean with and dump some junk or move it to some archive folder or backup drive.
Cleaning up the Workspace was the solution for me, when opening visual studio 2015 the Source Control Window will remain in a Loading phase, I had 2 workspaces name and name_1 and I removed both.
No need to delete the entire folder, though , keep in mind that if you do delete the workspace and have the files, you will need to force the get latest to be on the safe side
Getting Latest was soooooo slow. I was using a Colleagues PC and had deleted his Workspace.
After an hour waiting to get latest I got an error and realised my User Account didn't have Full Control on the folder, giving Write Access made Get Latest run x1000 faster:
Just to throw another solution in the mix! I had the same problem which seemed to be caused by several layers of working folders configured in my workspace (some overlapping ones too).
The issue was resolved by going to Manage Workspaces, then Edit and then removing the additional folder bindings.
in short "Run it as an administrator".
No one of those solution does work at all, I even search on this link:
Why is Visual Studio 2013 very slow?
In vain, just do this ONE simple step:
Go to your visual studio path, usually installed on this path:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE namely the file "devenv.exe" , then right click on it, click "Run an administrator" ===> then open your visual studio project.
So, you can just send a shortcut of "devenv.exe" to the desktop to easily run it as an administrator each time.
Have ^_^ Fun
You can keep workspace on local and change your workspace to this. I did that and my TFS speed was great :
1- Remove all mapped folders in workspace "Edit":
2- Change workspace folder to parent all of mapped folders:
I hope it is useful for you.
I'm not sure why I never noticed this before but when I "Get Latest" from TFS, the date and time on the files in my local working folder are set to the current date and time. This applies to the Created and Modified dates, even if no changes have been made (as I just did "Get Latest", nothing more).
Should I be concerned about the dates and times of the files not reflecting the true date and time the file was created and subsequently modified? I have the revision history in TFS so I'm not overly concerned but I gotta admit this feels wrong. Everything technically works but I want to know what's going on.
As you note, the default behavior in Team Foundation Server is to write file times to the "current" time (when you retrieved the file.) This is the default behavior of most version control tools and generally considered safe.
Setting time to the remote time can have negative consequences in many scenarios. For example, make will scan for files newer than the last build time. Setting file times to the server's time can impact the ability to determine which files have changed since the last build.
However, if you do prefer this behavior and are using at least TFS 2012 and Visual Studio 2012, you can enable it on a per-Workspace basis by setting "File Time" to "Checkin":
Additional details from Microsoft:
File Time:
Choose Checkin if you want the date and time stamp of each file to generally match the stamp of the changeset of the version in your
workspace. A few issues and exceptions are:
When you modify the local file, the date and time stamp will match the date and time when you modified the file.
This feature is available only if you are using Visual Studio 2012 or later and Visual Studio Team Foundation Server 2012 or later.
The setting does not apply to folders, unless there is a pending add or delete operation to a file contained by the folder.
You might not be able to build your code project incrementally. Instead, you will have to rebuild).
Choose Current if you want the date and time stamp to match the date and time when you last modified the local file. For example, a
team member checked in the latest change to the file on Monday. On
Tuesday, you perform a get operation to update the file. The date and
time stamp is set to Tuesday.
As mentioned, that is the default behavior of TFS. It's the fist version control system I've used where that is the default setting. The problem with using current time for files when a developer gets latest, is that you can only tell if you have the latest version by doing a file compare on each file. Three different developers on the same project will have 3 different date time values for the same version of a file. Either way, always do a project clean before creating builds. Why? Because you might have tweaked a file or two, then after testing, reverted to the latest checked-in version. In my experience it's always better to use the checked-in time.
TFS should not modify original File attributes in Source Control processing. Its build features should use their own properties to control latest checked in versions and for build control.
Getting files from TFS should place the original file back down on a system with their original properties unmodified. TFS is broken by hijacking the original file's properties for its own purposes. The original Microsoft VSS tool provided this option - shame on the TFS team.
Using Team Foundation server and BIDS 2008, I receive a screen to check out the dtproj file every time the Get Latest operation is performed.
Steps to Produce:
I have no files checked out after performing a "Get Latest" from solution explorer.
I click to open the solution file .sln from Solution Explorer and the SSIS project opens.
I then receive a "Check Out" screen asking me to Check Out the .dtproj file.
Any ideas how to keep this from happening?
Imperfect answer: How can I prevent BIDS from automatically checking out SSIS packages?
Also related: http://social.msdn.microsoft.com/Forums/en-GB/sqlintegrationservices/thread/654d556f-3826-4fd3-a36a-e7f20a059569
I have been using BIDS 2008 with TFS 2010 for quite sometime but never had the issue that you are facing. Here are the Source Control settings on my BIDS environment.
Some of the other links that might help you:
A project is automatic check outs everytime when i opens the solution in TFS 2008
How to stop Visual Studio from "always" checking out solution files?
This behavior appears to stop if you manually add the .database file to TFS through Source Control Explorer, making sure that the .database filename inside the .dtproj is the same name as the file you add to TFS.
Turns out the .database file is a local 'runtime' type file that Visual Studio creates each time. It is not an actual source file and should not be checked into source safe. What I think happens is that:
This file gets created by VS
At some point someone checks it into source safe, making the file read only in their working folder
Next time VS tries to create the file again. It can't (unless it's checked out) so it creates another one with a slightly different name
Because the filename is now different is changes the .dtproj file that references it. It therefore tries to check the .dtproj file out because a change has automatically been made to it
Chaos and confusion ensues
This is roughly what we did to fix this:
Delete any .database files from source control, ensure that it never gets added back again
Close VS
Backup and delete any .database files from local dev folder
Open VS and get latest
You might get 'this project couldn't be loaded' type errors in VS because the referenced .database file is missing
To get the project loaded, you need to get a valid .database file (these can get corrupted - check the file contents) into your local folder, and edit the .dtproj file in a text editor to point at the valid file
Once you have your .dtproj file working, check it in and have everyone get latest
Make sure no one ever checks in the .database file
Why oh why is it called a .database file when it has nothing to do with a database. When you search online for .database you get...... information about databases, not this annoying VS file.
Why Why WHY doesn't TFS's get latest work consistently?
You would have thought that feature would have been tested thoroughly.
What I have to do is, get specific version, then check both overwrite writetable files + overwrite all files.
Is my local setup messed up or you do this also?
TFS redefined what "Get Latest" does. In TFS terms, Get Latest means get the latest version of the files, but ignore the ones that the server thinks is already in your workspace. Which to me and just about everyone else on the planet is wrong.
See this link: http://blogs.microsoft.co.il/blogs/srlteam/archive/2009/04/13/how-get-latest-version-really-works.aspx
The only way to get it to do what you want is to Get Specific Version, then check both of the "Overwrite ..." boxes.
Sometimes Get specific version even checking both checkboxes won't get you the latest file. You've probably made a change to a file, and want to undo those changes by re-getting the latest version. Well... that's what Undo pending changes is for and not the purpose of Get specific version.
If in doubt:
undo pending check in on the file(s)
do a compare afterwards to make sure your file matches the expected version
run a recursive 'compare' on your whole project afterwards to see what else is different
keep an eye on pending changes window and sometimes you may need to check 'take server version' to resolve an incompatible pending change
And this one's my favorite that I just discovered :
keep an eye out in the the Output window for messages such as this :
Warning - Unable to refresh R:\TFS-PROJECTS\www.example.com\ExampleMVC\Example MVC\Example MVC.csproj because you have a pending edit.
This critical message appears in the output window. No other notifications!
Nothing in pending changes and no other dialog message telling you that the file you just requested explicitly was not retrieved! And yes - you resolve this by just running Undo pending changes and getting the file.
TFS, like some other source control providers, such as Perforce, do this, as the system knows what the last version you successfully got was, so get latest turns into "get changes since x". If you play by its rules and actually check things out before editing them, you don't confuse matters, and "get latest" really does as it says.
As you've seen, you can force it to reassess everything, which has a much greater bandwidth usage, but behaves closer to how SourceSafe used to.
It's hard to respond to a statement without examples of how it's not working, but it's crucial to understand that TFVC (in "Server Workspace" mode, which was the mechanism prior to TFS 2012) does not examine the state of your local filesystem. TFVC Server Workspaces are a "checkout-edit-checkin" type of system where this is by-design, an intentional decision made to massively reduce the amount of file I/O required to determine the state of your workspace. Instead, the workspace information is saved on the server.
This allows TFVC Server Workspaces to scale to very large codebases very efficiently. If you are in a multi-gigabyte code base (like Visual Studio or the Windows source tree) then your client does not need to scan your local filesystem, looking for files that may have changed, because the contract you have with TFS is that you will explicitly check a file out when you want to edit it.
You are expected to not mark a file as write-only and change it without explicitly checking it out first. If you go down this route, then the server does not know that you have made changes to your file, and performing a "Get Latest" operation will not update your local workspace, because you haven't told the server that you've made changes.
If you do subvert this mechanism then you can use the tfpt reconcile command to examine your local workspace for changes that you have made locally.
If you find yourself using "Get Specific Version" and selecting the "force" and "overwrite" options, then it is very likely that you are in the habit of bypassing all of the enforcements that TFS has implemented to keep you from hurting yourself, and you should probably consider TFVC Local Workspaces.
TFVC Local Workspaces provide an "edit-merge-commit" type of version control system, which means that you do not need to explicitly check files out before editing them and they are not read-only on-disk. Instead, you simply need to edit the file, and your client will scan the filesystem, notice the change, and present this as a pending change.
TFVC Local Workspaces are recommended for small projects that do not require fine-grained permissions control, since they present a much nicer workflow. You are not required to be online, and you do not have to explicitly check files out before editing them.
TFVC Local Workspaces are the default in TFS 2012, and if they are not enabled for you, then you should ask your server administrator. (Organizations with very large codebases or strict auditing requirements may disable TFVC Local Workspaces.)
Eric Sink's excellent book Version Control By Example outlines the differences between checkout-edit-checkin and edit-merge-commit systems and when one is more appropriate than the other.
The Professional Team Foundation Server 2013 book also provides excellent information about the differences between TFVC Server Workspaces and TFVC Local Workspaces. The MSDN documentation and blogs also provide detailed information:
Decide between using a local or a server workspace
Server workspaces vs. local workspaces
Team Foundation Server – Trying to understand Server versus Local Workspaces
Team Foundation Server (TFS) keeps track of its local copy in a hidden directory called $TF.When you issue the "get Latest Version", TFS looks into this folder and see weather I have the latest copy or not. If it does it will not download the latest copy. It does not matter if you have the original file or not. In fact you might have deleted the entire folder (as in my case) and TFS won't fetch the latest copy because it does not look into the actual file but the hidden directory where it records changes. The flaw with this design is, anything done outside the system will not be recorded in TFS. For example, you may go into Windows explorer, delete a folder or file and TFS wont recognize it. It will be totally blind. At least I would expect there Windows would not let you delete this file but it does!
One way to enforce the latest copy is to delete the hidden $TF folder manually. To do that, go to command prompt and navigate to the root folder where you project was checked out and issue this command
rd/s $tf // remove $TF folder and everything inside it
If you want to just check the hidden folder, you can do it using
dir /ah // display hidden files and folders
Note: If you do it, the tf will think you do not have any local copy even though you have it in files and it will sync up everything again.
Caution: Use this method at your own risk. Please do not use it on critical work.
"Get latest version" by default will only download the files that have changed on the server since the last time you ran "Get latest version". TFS keeps track of the files you download so it doesn't spend time downloading the same version of the files again. If you are modifying the files outside of Visual Studio, this can cause the consistency problems it sounds like you are seeing.
Unfortunately, there has to be one or more bugs in TFS 2008, since this problem regularly crop up on developer machines and build servers where I work as well.
I can do Get Latest, I can see in the history list of the project that there have been commits after I last did a Get Latest, I have not touched the files on disk in any way, but after the "Get Latest" function has completed, when I check the TFS tab, some of the files still says that they're not the latest version.
Obviously TFS is able to determine that I have old files locally, since the list says so. Yet, Get Latest fails to do that, get the latest version. If I do what you did, use the Get Specific version, and check the two checkboxes at the bottom of the dialog, then the files are retrieved.
We changed our build servers to always use the Get Specific version type of function instead, so this part now works, but since our build server (TeamCity) also relies on checking if there have been changes to the files in order to kick off a build, sometimes it lapses into a "nothing changed, nothing to see here, move along" mode and does nothing until we forcibly run the build configuration.
Note that I have experienced this problem on a machine that is never touched, except for get latest + build, both manually, so there's nothing tampering with the files. It's just TFS getting confused.
One time this cropped up I verified that the files on disk was indeed binary identical to the version previously retrieved, so no manual tampering had been done with the files.
Also, I fail to see how TFS can "know" whether files have changed on disk or not without actually looking at the contents. If one part of TFS can see that the files are indeed not the latest version, then the Get Latest version should absolutely be able to get the latest version. This in reference to comments to other answers here.
It might because you are login TFS as the same user, and the workspace name (based on machine name by default) is also the same, so TFS thinks your are on the same machine and same workspace, thus you already have the latest version of the files, so it wont get them for you.
try rename your machine, and create a new workspace as a new machine.
Go with right click: Advanced > Get Specific Version. Select "Letest Version" and now, important, mark two checks:
The checks are:
Overwrite writeable files that are not checked
Overwrite all files even if the local version matches the specified version
WHen I run into this problem with it not getting latest and version mismatches I first do a "Get Specific Version" set it to changeset and put in 1. This will then remove all the files from your local workspace (for that project, folder, file, etc) and it will also have TFS update so that it knows you now have NO VERSION DOWNLOADED. You can then do a "Get Latest" and viola, you will actually have the latest
I had the same issue with Visual Studio 2012. No matter what I did, it didn't get the code from TFS source control.
In my case, the cause was mappings a folder + subfolder from the source control separately but to the same tree in my local HD.
The solution was removing the subfolder mapping using the "manage workspaces" window.
Most of the issues I've seen with developers complaining that Get Latest doesn't do what they expect stem from the fact that they're performing a Get Latest from Solution Explorer rather than from Source Control Explorer. Solution Explorer only gets the files that are part of the solution and ignores anything that may be required by files within the solution, and therefore part of source control, whereas Source Control explorer compares your local workspace against the repository on the server to determine which files are needed.
It could happen when you use TFS from two different machines with the same account, if so you should compare to see changed files and check out them then get latest then undo pending changes to remove checkout
This worked for me:
1. Exit Visual Studio
2. Open a command window and navigate to the folder: "%localappdata%\Local\Microsoft\Team Foundation\"
3. Navigate to the sub folders for every version and delete the sub folder "cache" and its contents
4. Restart Visual Studio and connect to TFS.
5. Test the Get Latest Version.
In my case, Get specific version, even checking both check boxes and undoing all pending changes didn't work.
Checked the work spaces. Edit current workspace. Check all paths.
The solution path was incorrect and was pointing to a deleted folder.
Fixed the path and get latest worked fine.
Every time this happens to me (so far) is because I have local edits pending on the .csproj project file. That file seems to keep a list of all the files included in the project. Any new files added by somebody else are "not downloaded" because they are not in my locally edited (now stale) project file. To get all the files I first have to undo pending changes to the .csproj file first then "get all". I do not have to undo other changes I have made, but I may have to go back and include my new files again (and then the next guy gets the same problem when he tries to "get all"...)
It seems to me there is some fundamental kludginess when multiple people are adding new files at the same time.
(this is in .Net Framework projects, maybe the other frameworks like Core behave differently)
just want to add TFS MSBuild does not support special characters on folders i.e. "#"
i had experienced in the past where one of our project folders named as External#Project1
we created a TFS Build definition to run a custom msbuild file then the workspace folder is not getting any contents at the External#Project1 folder during workspace get latest. It seems that tfs get is failing but does not show any error.
after some trial and error and renaming the folder to _Project1. voila we got files on the the folder (_Project1).
Tool:
TFS Power Tools
Source:
http://dennymichael.net/2013/03/19/tfs-scorch/
Command:
tfpt scorch /recursive /deletes C:\LocationOfWorkspaceOrFolder
This will bring up a dialog box that will ask you to Delete or Download a list of files. Select or Unselect the files accordingly and press ok. Appearance in Grid (CheckBox, FileName, FileAction, FilePath)
Cause:
TFS will only compare against items in the workspace. If alterations were made outside of the workspace TFS will be unaware of them.
Hopefully someone finds this useful. I found this post after deleting a handful of folders in varying locations. Not remembering which folders I deleted excluded the usual Force Get/Replace option I would have used.
I encountered the same problem:
My development server was corrupted and restored, but the information restored was from a few days ago.
TFS was updated that all the files are up to date, but in practice my files were correct a few days ago!
Nothing I did helped. get latest did not get the latest version.
At the end I got specific varision from a month ago. my files were updated accordingly, and then I did get latest.
And it worked. the files have been updated.
I'd like to get a batch of files from a directory by date except for one file. I'd like to then look at all the files and see that yes, files 1 to n are the old versions and file 0 is the new version.
The simplest way to do that, seems to me, is to get the files and have the local file's timestamp be the last checkin time of that file. However, I don't think that's possible in TFS without custom coding. Is there an easy way to do this?
In current version of TFS (including TFS 2010), the files timestamps are always the time that they were downloaded by doing the get.
Don't quite understand the reason behind what you are trying to do, but it sounds like the easiest thing would be for you to write a simple .NET class or powershell script that did what you needed using the VersionControl part of the TFS API. You'd be able to query last-check-in dates etc without even haveing to download the file in question - you'd just look at the changeset ID's of each file to see which is the newest.
Yes, there is in easy way to do this if you are using at least TFS 2012 and Visual Studio 2012. From the Visual Studio documentation on advanced workspace options:
File Time:
Choose Checkin if you want the date and time stamp of each file to generally match the stamp of the changeset of the version in your
workspace. A few issues and exceptions are:
When you modify the local file, the date and time stamp will match the date and time when you modified the file.
This feature is available only if you are using Visual Studio 2012 or later and Visual Studio Team Foundation Server 2012 or later.
The setting does not apply to folders, unless there is a pending add or delete operation to a file contained by the folder.
You might not be able to build your code project incrementally. Instead, you will have to rebuild).
Choose Current if you want the date and time stamp to match the date and time when you last modified the local file. For example, a
team member checked in the latest change to the file on Monday. On
Tuesday, you perform a get operation to update the file. The date and
time stamp is set to Tuesday.