I'm developing in Visual Studio 2005, using TFS as the source control. Whenever I haven't been working on the solution for a while, I always do a recursive Get Latest in Solution Explorer.
However, this doesn't always seem to work. If I know I don't have the latest version of a file, even right-clicking this (in Solution Explorer), choosing Get Specific Version and ticking the "Force get" box doesn't work.
I seem to need to open up the TFS Source Control window, and there force a Get of the file in question.
Also, the Solution Explorer often has the little "checked out to someone else" icon next to files, but when I check in Source Control, they're not checked out at all!
I'd just like to know if these problems are widespread, whether they persist in VS2008 (I haven't used TFS for a big project in 2008 yet), and if there are any fixes or workarounds.
1) I would not make a habit out of Get Latest from Solution Explorer. Even if it always worked 100% bug free, it is far slower and less reliable than doing it from the command line or Source Control Explorer. SlnExp has to crawl your whole project structure and issue non-recursive calls...pseudo algorithm:
parse sln file
foreach project in sln
TFS_GET makefile
parse makefile
enumerate sourcefiles[]
TFS_GET sourcefiles[]
loop
SCE requires no parsing and issues one single recursive webservice call. In addition to the performance gain, this is much safer:
(a) Build-time dependencies aren't always part of a project's file list. Executable tools, 3rd party assemblies, and deployment scripts are all common examples. SCE will download them, SlnExp won't.
(b) Scoping Get calls down to specific files won't yield the expected result when a file is renamed or moved. At best, the "old" name is deleted from disk; at worst, nothing appears to happen at all. (this may be the cause of the bug you reported) In order for a file to truly be renamed/moved in sync with the server, the old & new paths must both be inside the scope of the Get.
2) There have been many bug fixes to the SlnExp "glyphs" over the years. I won't claim that VS2008 SP1 is perfect in this regard but it is definitely improved.
Sometimes Get specific version even checking both checkboxes won't get you the latest file. Most commonly what happens is that you've made a change to a file, and you 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) before you do 'get latest'
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's 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 :
check 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.
Yes 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.
Related
Whenever I try to delete (or even exclude) any file from my VS2015 C++ project, I get the following message:
File '...' cannot be removed. The most likely reason is that the file is under source code control and cannot be removed at this time.
Trying to search for this error message gives no results anywhere - am I the only one that has ever got it?
I use perforce, and all the files are checked out, so VS should not know anything about version control.
The only solution I can find is to remove the files from vcxproj file manually, which is very tedious.
Update: the problem seems to be with Perforce plugin. Disabling it allows me to remove files again. This is strange, because I never configured it for this specific project. I also tried to switch source control to None, but it kept resetting every time I restart VS.
I just ran into this issue with Visual Studio 2017. I did some pretty extensive troubleshooting, and found a workaround:
Open the solution/project for which you are seeing this problem.
Open a connection to a perforce depot - even though your solution isn't supposed to be managed by Perforce - by using this option: File / Open Connection to a Perforce Depot...
You should see either a warning dialog or a warning line in the Output tab under Perforce Source Control that says something like "Solution is not under your client's root folder". If you don't see either, you should probably either move your entire solution somewhere that isn't in your client spec (if possible), or exclude the entire solution folder from your perforce client spec. That way, P4VS shouldn't automatically add files in that solution to Perforce.
Navigate to:
Tools / Options / Source Control / Perforce - General
...and uncheck this option to suppress the annoying warning dialog from step 3 that would otherwise appear every time you open that solution:
Warn if solution is outside workspace root
Now, you should be able to remove files again without P4VS interfering. (Fair warning: This workaround may have other side effects that I don't know about, but it has worked for me so far.)
Nothing worked for me so I just opened the project file in a text editor and manually removed the offending files. At some point my build target had changed as well, so a possible reason for this happening was I was trying to remove the files while a different build target was selected to when they were added.
I'm currently going through checking in changes I have made to my code. There are well over 100 files which have been changed, and I am repetitively getting this error for various files.
Could not find file '[File Path]'.
While I can understand the reasoning for the error, and I know on how I can fix it, how would I display all files which are throwing this type of error when checking in? Consider it to resolving merge conflicts, you would be given a list of files which require attention, you can easily see multiple and deal with them. Unfortunately while checking in changes, it only displays on error at a time.
The current process I am going through is Check In > Error Thrown > Fix Error and repeat. It would be so much more faster to be able to see all affected files and deal with them unlike the way I am currently doing.
I am using TFS 2015 on Visual Studio 2017 Enterprise.
Thanks in advance.
There isn't a good solution (at least not one I'm aware of) to the problem you are facing. Typically in these situations, I recommend to people to backup your changes to another folder and undo your changes in your working copy. From there copy back in the files you care about and if you renamed or delete files, make sure you do it through Visual Studio in either the solution explorer (provided your solution is correctly connected to version control) or in the source control explorer.
Another option is to try and reconcile the changes in source control explorer. You can use the tf command line tool to get a list of pending changes. Running tf status at the root of your workspace will give you a list of pending changes. You can then compare the output with what you have locally in the file explorer. Any files that need to be renamed or deleted should be done in the source control explorer.
As a side note, when using TFVC you should always do all of your rename and deletes through source control explorer to avoid this issue. Also, try to limit the number of changes you make between commits. Having over 100 files changed in one commit will quickly get you into a situation like you are in. Smaller, incremental commits are always preferred over large sweeping changes.
I have a project that I have been using VSS source control from the VS Pending Checkins tab. This has been working until recently. Now when I make a change to the code, I do not get an entry in the Pending Checkins tab.
I saw this article, but did not see a Go Online option either when right-clicking on the solution or under File -> Source Control. Probably because that person was using TFS rather than VSS.
I tried breaking the source control links and creating a new tree, but it still didn't check out automatically when I made changes. I have been using the Check Out For Edit option, and then checking in, but this gets all classes whether I make changes or not. I use source control in VS because the list makes it simple to determine whether I need to check something in or not.
Does anyone have an idea as to why this may have stopped working with this project. It is still working in other projects. I do have "Check out automatically" selected for On Save and On Edit. Allow checked-in items to be edited is not checked, nor are any of the other options under Source Control -> Environment.
Thank you for any suggestions you may have.
UPDATE: I just added a new class to the solution, and that class appears under pending checkins. However, I also made several changes to other classes, and none of them are appearing under checkins.
I too rely on SourceSafe via Visual Studio to automatically check out files. But it usually just works by default although with certain assumptions you need to know that I learned from this post which explains the risky methodology:
If you Get all files without checking them out then the files will be read only as you can see in Windows Explorer properties. Then, when you type your first edit to any file, VS/ VSS first checks for the read-only attribute on that file. If it is read only then the file will be automatically checked out (this is the default option). Then, when you are ready to check-in a set of files, VS will show you all “Pending Check-ins” and you can check them in as a set.
I have relied on this for years as it has been working great for me in our environment until a few weeks ago when many of my source files lost their read only attribute somehow. So without read-only, some of the files were not getting checked out and therefore not getting checked in. And that’s really hard to detect until your hard-drive crashes and you try to build from another machine!
And I found a method here to fix the read only attributes:
check in all files that were edited (used VSS to find out which files where
changed [using differences] even though VS did not checked them out). Then did a Get Latest with
overwrite of local files and made sure the "Keep writable" checkbox was not
checked.
On the current project I am working on, there is, at the moment, a large churn of code, which means updating from source control can mean at times many csproj file changes. As we all know, VS2010 doesn't have a "Reload all" button, but you must reload each project and confirm each reload.
Is there a method where either the project is auto-reloaded or the IDE can detect this and ask for a solution reload?
Finally found a solution:
http://lostechies.com/jimmybogard/2011/01/27/reloading-all-projects-with-vscommands/
Quoting from the site:
Quite often I’ll find myself working
in situations where multiple projects
have changed, and Visual Studio asks
to reload them, one at a time. This
happens when I’m working a lot with
source control, and doing things like
switching branches, performing merges,
or just integrating upstream changes.
I have to click “Reload” a million
times for each project that changed on
disk, and it’s quite annoying. On top
of that, VS forgets which files I have
open, so every file that I was working
on gets closed.
I may be the last VS user to find out
about this, but a free lite version of
the VSCommands plugin is available on
the Visual Studio Gallery that does
just what I need – reload all changed
projects at once, preserving which
files I had open:
It's a pain, but the best option I've found is to Close the solution before Getting the latest source code.
If there are more than two changed projects, it is faster to manually unload&reload the entire solution than it is to Get and wait for it to unload&reload the affected projects only - reloading projects is achingly slow (even disregarding having to click the OK button for every project that changed).
(In my mind the real question is: Why does it ask that question at all??? If you Get the latest source code, there is absolutely no sane reason why you would want to only use part of it. It's like a petrol station attendant saying "You've bought some fuel. Would you like me to now actually put it in your car, or shall I just pour it out on the ground?")
Well, that doesn't work if your references paths changed in the csproj file and your using something like the sysinternals junction tool to change a symlink. E.g. tool switches D:\Projects symlink from D:\Baselines\1.0\Prjects to D:\Baselines\2.0\Projects , and because someone changed the folder structure between 1.0 and 2.0, your .csproj file suddenly points the dll path from ....\References\some.dll to ....\References\3rd-Party\some.dll . I know that is a special case, but happens (e.g. in my company).
There is an alternative solution though, one which I highly recommend as it has other benefits, too: the not-so-well-known VS 2010 Extension Solution Load Manager. It defers loading of Projects to the background, or until manually loaded, improving solution load time a lot for large solution files. It has this "reload solution" button in it's menu (unfortunatlely there seems to be no shortcut) which then reloads all solutions from scratch, skipping/backgroundloading the solutions you set. A Microsoft guy commented on his blog that they wanted to include something similar into VS 2010, but the feature didn't quite make it.
Sure, it may take longer then "just" one click and updating 100 documents, but it solved my problem of (relative) reference path changes, and gives a nice speed boost every time I open an at least medium sized solution.
Edit as of Oct 2013
VS2012 includes this functionality by default. At least the async loading stuff. The "don't load at all" functionality is unfortunately only possible by using manual "unload project" in VS2012. But as pr-project memory consumption did go down with VS2012, it's not that big of a deal anymore.
If you have checked the option "detect when file is changed outside the environment" in the "Documents" section of options, projects and files are reloaded when changed. It works for me when switching branches in git.
I have a VS2005 solution which contains a variety of projects (C++ DLLs, C++ static libraries, C# assemblies, C++ windows executables) that are combined in various ways to produce several executables. For some reason, every time I open the solution, VS2005 wants to check out one of the projects for editing. The project is not modified in any way, it's just checked out. If I configure VS2005 to prompt before checking out, I can cancel the auto-checkout during load with no ill effect that I can see. It may or may not be relevant, but the project it keeps checking out is cppunit version 1.12.0 (the static lib version). How can I stop this annoying behavior?
Other potentially relevant (or not) details:
Source control is Team Foundation Server (not Visual SourceSafe)
no .suo or .ncb files are checked in
the .vcproj and .vspscc files are being checked out
When I close the solution or shut down Visual Studio, I'm asked whether I want to save changes to the project. Answering yes results in no changes to the file (Kdiff3 compares my local file to the server version and reports"files are binary equal")
Attempting to check in the "modified" files results in a Visual Studio message saying "No Changes to Check In. All of the changes were either unmodified files or locks. The changes have been undone by the server"
As Charles and Graeme have hinted at, Visual Studio constantly make changes to user option files and such on the backed even if you don't make changes to the project directly.
I'm not sure what information is being stored but I do know that it happens. Common remedies is to not include the *.suo files. I also don't stored anything in the bin or obj folders in sauce control as this can have a similar effect as your talking about (if you build). (Checks out the project upon a build. Thought this does take an action to happen).
Overall it is unavoidable. It is just how VS2005, 2008 work.
Does this answer your question?
Regards,
Frank
There are two reasons I've encountered that cause this behavior.
The first is old source control bindings. If you have a project that used to be managed by another source control tool, it might have leftover bindings in the project file. Open the project file, and change the following settings from something like this:
SccProjectName="$/Team/Platform/Projects/MyProject"
SccAuxPath="http://teamFoundationServer.example.com:8080"
SccLocalPath="."
SccProvider="{88888888-4444-4444-4444-BBBBBBBBBBBB}"
to this:
SccProjectName="SAK"
SccAuxPath="SAK"
SccLocalPath="SAK"
SccProvider="SAK"
Different project types are defined in different ways. The above example is from a .vcproj, C# projects are in XML, VB looks like something else, but the meanings are the same. Simply set all four values to the constant string "SAK" and Visual Studio will automatically handle source control. See Alin Constantin's blog for details.
I haven't yet discovered the root of the other reason, but the project that is giving me trouble is also CppUnit 1.12.0! I'll keep digging and post my findings.
John
Have you put a .suo or .ncb file into source control perhaps?
Have you tried closing VS2005 after it checks out cppunit and then seeing if any changes were made?
I often encountered something like this with Web App solutions where the project file wasn't actually saved until you closed studio down and reopened it.
Just to clarify, I'm assuming that you mean Visual SourceSafe2005 is causing the problem, not Visual Studio. (FYI, Visual SourceSafe is usually abbreviated VSS.)
I've experienced this issue with VSS before. I think the limitation is really fundamental to Visual SourceSafe: it's just not that good of a product and I would move to something else if it's a decision you can influence.
If you can move to something else, I recommend Subversion for a small or medium-sized project. It's free, and does not use the pessimistic locking mechanism that Visual SourceSafe uses by default. There's an excellent Visual Studio add-on called VisualSVN that will give you the same functionality in the IDE (seeing what files have changed, etc.) that you get out of the box with VSS.
If you cannot change source control systems, I believe Visual SourceSafe has a mode called "non-exclusive checkouts" or something like that that uses the optimistic locking that Subversion and other source control systems use. Try setting that option at least for the files that are obviously not being changed and see if that resolves the issue.
I get this a lot when one of the projects in the the solution has source control information with path information that is not the same in source control as on your workstation. When VS opens the project it will automatically attempt to check out the project in question and
To fix it, you're best off having everyone who uses the project remove their local copies and do "get latest version..." to grab what is in your source control database.
you can also check the .sln file and look in the GlobalScxtion(SourceCodeControl) area for each project's information and see if the relative path is not how you have the projects stored on your workstation - though manually changing this file vs. doing a "Get Latest Version..." is much more likely to cause problems for the other developers who use the solution as well.
Your cppunit project is probably automatically creating one or more additional files when the project first loads, and then adding those files to the project. Or else one of the project's properties is being changed or incremented on load.
If you go ahead and check the project in, does it check itself out again next time you load it? Or does checking it in fix the problem for awhile?
Very often this sort of behavior is caused by VS trying to update source control bindings.
Graeme is correct, VS will not save project or solution files until you close VS.
I would let VS check the files out, then close VS, then diff them.