I changed a lot of files in one of my ASP.NET Solutions and checked-in. Afterwards I realized I wanted to role back to my original files. I am aware I could have just went to Source Control explorer and rolled back the changeset but I went about it wrong. Since I took a backup of my entire project directory prior to doing this I figured it would be easy to simply just replace the directory with my backed up files.
After replacing the entire directory with the backup and When I open the solution I get the following message:
One or more source control bindings for this solution are not valid
and are listed below. Source control bindings can be modified by
selecting File, Source Control, Advanced, Change Source Control from
the main menu.
Then all of the .csproj files are listed below.
I followed the instructions that I saw on many websites saying unbind then rebind and it is not doing anything for me.
My first question is why did this happen if it is the same exact set of files that have all of the source control bindings.
My second question is how can I go about getting this backed up solution in source control again?
I expect it to be in source control showing me the pending changes so that when I check-in the latest version in source control will be my replacement version.
Unlike windows file system, you shouldn't simply copy and past the backup files. It will definitely cause source control binding conflicts as you encountered.
You should use rollback entire changeset feature. This will influence your source control in TFS. If you roll back a file to an earlier version, tfs will eliminating the effect of all changesets that occurred after that version. More details please take a look at this tutorial: Roll back changesets
Since you just need to go back the old version files, you could now roll back your changesets to the one you back up the entire project. Check in the roll back operation.
Another way is as below if unbind/re-bind the project is not work:
Unbind project in Change Source Control
Unload project in Solution Explorer
Reload project in Solution Explorer
Note: If you use above option, the TFS consider all project files as newly added files to the solution.
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 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.
2 projects under TFS Source Control.
DependancyProject.sln
AppProject.sln
With AppProject referencing DependancyProject.
-
The issue I have is with an Installer project in the AppProject.
It has DependancyProject.dll as a 'reference'(?) where it tries to include it in the GAC.
When I try to build this project, to create an MSI to install the App, I get the error
The item $/Assemblues/DependancyProject/bin/debug/DependancyProject.dll is locked for check-out by USER in workspace HIS-PC-NAME.
(The PC in question is not dead and not used)
The dll is not (as far as I can see) checked into Source Control.
The path it references anyway does not exist when I browse through it (no bin folder).
The DependancyProject is refernced by pretty much every project in Source Control, and i've never had any issues with it.
It builds, all the other projects build.
It's just this one Installer Project which doesn't.
And I can't see why it would need to try and modify it anyway.
All it needs to do (I'm assuming) is make a copy of it.
Any ideas here?
Some files are configured as "non-mergeable" in TFS, which means that they'll be locked when changes are pended on them. The default list includes a variety of binary files, including .dll files. Note that this lock applies to all pending changes - including adds.
It's likely that the other developer in question accidentally pended adds for his bin directory - and any binary files in that directory (ie, most of them) would have been locked as well due to being in that unmergeable list.
You will not be able to pend other changes (including an add in a different workspace) while these items are locked. To break this lock, the other developer can do this by undoing the pending changes, or a server administrator can do it using the Find in Source Control functionality in the Team Foundation Server Power Tools.
That said, I don't know why your build process is trying to pend an add on that file.
I had the same problem, and this guide solved all my problems.
The file was actually locked by me, but in a different work space (old computer).
Had to use the tf undo command to unlock the files.
If you are not going to use that workspace again, you can delete it by going to workspace pull down, selecting workspaces, and enabling the check box "Show remote workspaces". you can then select it and remove it.
I know this is possible because one of my older solution files has a mix of some projects under source control and some not.
However I can't seem to reproduce that configuration with a newer solution. Every time I add a project to the solution it acquires a yellow cross and under Pending Checkins the project is listed as a Newly added file.
This is with the Perforce plugin for VS2008.
I have tried adding a brand new project, vs an existing project. I have tried p4 obliterate. I have tried disconnecting and reconnecting source control. Binding and unbinding.
After all this, every time I try and add the project it gets a pesky little yellow cross. I can't seem to tell Perforce and VS that, while I do want source control on the majority of the solution, I don't want this one project file under source control.
I see now that the way to have multiple projects under one solution, some projects under source control, and others not ... is to avoid having the solution itself under source control. That way I get just the projects I'm interested in checked in and out and the rest ignored.
Which, in fact, on closer inspection, is how I've managed (by muddle, mistake or design, I can't remember) to solve this in the past.
Under File, Source Control, go into the Bindings dialog. Click the project in question and unbind it. You can leave the other projects, and the solution itself, bound to source control.
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.