SourceSafe Related Error message I got in Visual Studio 2010 when I tried to edit a file:
File is already checked out by the current user in a different location
Background:
For some reason source safe saved the files 3 directories deep.
For Example, The solution files were located in: VS2010Apps\CCP_Utility\CCP_Utility\CCP_Utility\
The solution files should be in the root directory: VS2010Apps\CCP_Utility
I moved the files to VS2010Apps\CCP_Utility to create this error and now I can't edit my project....
Question:
How can I edit my files again and keep the correct directory structure???
Do I Just delete the source safe files and re-add it to source safe or what?
It sounds like VSS is expecting those files in a particular directory. To solve this:
find and make the path that VSS is expecting; the one with ccp_utility x 3.
check-in (all files) to VSS.
if you don't care about version history at this point, delete the project from VSS.
disconnect/unbind your solution from version control.
make the directory layout on disk as you need.
drag & drop the root folder of your new layout on disk into VSS Explorer. Suggest make it a brand new path (aside your old project) in VSS, to avoid any complications.
you now have a 'new project' as far as VSS is concerned.
ensure your bindings are correct, and you should be able to continue as per normal.
This happened to me when my work machine was replaced and I had forgotten to check in some files on my old machine before the change. My local copy of the file was the one I wanted to work with, but VSS had it marked as checked out on a different machine [my old machine].
I just opened the Source Safe Client, browsed to the affected files and checked them in: the client asks if I wish to proceed using the local file (Yes) - then just reloaded the project in Visual Studio.
Related
I had a solution containing the following projects:
Web App 01
Server Control Foo
Server Control Bar
Each project has its own directory in the root of the solution directory, directly mirroring the structure of the solution.
I branched the solution, then combined items 2 & 3 into a new project within that solution, then deleted projects 2 & 3. I committed the changeset. The resulting structure in VS2015 solution explorer was this:
Web App 01
Server Control Library
I then merged the branch, and committed this also. Over time, branching and merging has got slower and slower. On inspecting the file structure of my hard drive, and Visual Studio Online, I see this folder structure:
Web App 01
Server Control Foo
Server Control Bar
Server Control Library
Despite Solution Explorer not listing the deleted projects, the folders and files from all my deleted projects remain. Despite their status, they are also being branched every time. Is this the correct behaviour, and is it safe to delete them? If so, should I delete using VSO, Windows, or VS2015?
I assume you are using TFVC (changeset, branched the solution).
First, delete the projects from solution (right click the project in VS > Remove) just remove the relationship between projects and solution, the projects’ files and folder are still existing in the hard drive. So you need to delete these files and folders from hard drive (file system).
Secondly, these files are still existing in the source control too, because they aren’t marked as deleted if you just remove projects from solution, so check in changes just affect the solution file, it won’t delete files from source control. So you need to delete them from source control and it’s safe.
Steps to delete files:
Go to Source Control Explorer in VS
Right click Folder or file > Delete
Check in changes
BTW, the files still can be restored if you don’t permanently destroy them. (Destroy command), more information, you can refer to this article: Delete or restore files and folders in Team Foundation Version Control (TFVC)
My Visual Studio projects are located in C:\Users\MyName\ProjectName.
To make life easier (I thought), I created a file system link in the root called TFS.
(i.e. C:\TFS points to C:\Users\MyName\Projects)
I always open my projects from the link (i.e. C:\Tfs\ProjectName\ProjectName.sln) and my TFS local paths uses the link.
This work fine most of the time but someVisual Studio and TFS think files are in C:\Users\MyName...
i.e. If I look at the properties of projects in a solution, one can be in C:\Tfs and another in C:\Users. I have verified that there are no absolute paths in any solution or project files.
When this happen and I add a new file to a project TFS becomes a real mess. TFS thinks the new file is in C:\Users and is not versions controlled but at the same time there is a file with the same name in the C:\TFS folder so I need to resolve a conflict. I can resolve the conflict but TFS starts versioning the C:\Users file. i.e. the local folder for the project is C:\TFS... but according to TFS (and pending changes) the new files live in C:\Users.
I have not found a way to change the local name of file, only a folder.
Is there a way to resolve this or should I just get rid of the link?
(It works slightly better with a TFS local workspace but the problem is still there)
<tl;dr>
Symlinks are funny things and because TFVC stores binding information outside of the source control folder, it may get very confused when your repository is stored in or includes them.
Details
Opposed to Git, Mercurial and Subversion, TFVC doesn't just keep the binding of disk to repository in a subfolder of the repository (in case of a server workspace it doesn't keep this data on disk with the repository at all). It also stores it in a number of other places, namely the TFS server and your user profile.
When you look at a subversion or git repository you'll find the .svn or .git folders which contain the information of which folders on disk map to the repository.
With TFVC this information is not only stored on disk (in case of Local workspaces), but also on the server (machine name, server path, local path) and in your user profile (under AppData\Local\Microsoft\TeamFoundation\). These configurations store the full paths and these are used to see if a file is under version control or not. The reason why Local workspaces improve things, is because they add the tf$ folder with some of the binding information.
Since a workspace mapping can map a folder in your repository only to one folder on disk, the use of symlinks confuses the TFVC client. You might consider this a bug, since Microsoft should be able to resolve the link (depending on the link type), but Visual Studio assumes you are not using links. Other reasons why this (potentially) confuses Visual Studio is that file size and other attribute changes are not always signaled in case links are used (date changed and file size may not be notified until Visual Studio is told to refresh the solution). The Read-Only bit (which TFVC uses in case of server workspaces) also has special behavior in case links are used and may cause issues of undetected checkouts.
More on the strange edge cases caused by links, can be found here.
I'm not sure why you'd want to use a link in this case, the sources are already stored in TFS, so a backup of your profile doesn't add much and only makes you system slower in case you have a roaming profile. Plus, workspaces are machine bound and should never "move between machines" magically anyway.
You can submit a suggestion on the Visual Studio User Voice, or file a bug on Connect if you want to see this behavior changed, but to solve your problem, use normal folders and map your files to a unique location.
Just keep in mind, very few applications in Windows are built to handle Symlinks, and those that are may cause strange behaviors. Windows explorer (file open dialogs and drag&drop) may provide the original file location, instead of the link location for certain actions and changes to attributes in one location may not be visible in the linked location.
As you can see here, systems will be able to see the difference between symlinks and real directories, and thus may act on that knowledge:
OK, so one or more of the references required that the solution be in C drive. I cut-pasted the solution from one folder in D drive to another in C, and bam, all TFS bindings went down the drain.
I've changed my workspace local folder to point to my new folder, so I'm not sure why TFS doesn't recognize it. OK, I admit I was working without TFS connection for a period of time, but now I would like to get some changes checked in. But when I go to File -> Source Control -> Advanced -> Change Source Control, it tells me that the Status for my .sln and .proj files are all Invalid.
I've tried unbinding and rebinding projects but this doesn't seem to work.
This is frustrating. Is there any other way than to delete and re-download the entire solution? Or is this a caveat of TFS, is there any file on my hard drive that defines my solution location? It's 10GB worth, I don't want to need to do this every time I move my solution, especially when I actually have all the files on my hard drive.
If I understand you right, you had your sources connected to TFS on your D: drive. For some strange reason you needed to move them to C: drive and you did this by using Windows Explorer (or any other not TFS related tool)? After that you changed your code and now want to check it in to TFS, but it denies it. Right?
The problem is that TFS didn't got any information about your moving and changes you made in the new location. This only works if you used "local workspace" setting when creating the workspace or if you changed your workspace to the new location and checked out the files there.
How I would "fix" this:
Copy/save your current code changes in a temp folder
Open VS/TeamExplorer and create/change your workspace to the location where you want your sources on C:
Do a "Get Latest Version" on your workspace, to download the sources from TFS and to update the workspace in TFS
Checkout all files in your workspace (checkout root folder with recursive option)
Copy your saved code from step 1 into your workspace
check in your changes (check in on root folder of workspace again with recursive option)
your sources are now linked to and stored in TFS
Under "Tools-> Options-> Source Control -> Environment -> Saving/Editing" set the value to check out automatically, so that VS will to the checkout for you automatically when changing a file in VS.
I have a seemingly common problem, but cannot find a common solution that will work for me. I recently had my computer re-imaged and am now in the process of redownloading a solution from TFS. One of the solution folders contains 2 folders that list "Not downloaded" in the "Latest" column of the Source Control Explorer. When trying to open the solution, I get the error "The project file could not be loaded. Could not find file x". I've tried the methods listed below, to no avail:
Get Specific Version, checking Overwrite options
Deleting, .suo file, restarting VS2010
tf get /force
Remove mapping, deleting local files, remapping entire TFS project to local folder
tfpt rollback /changeset where the last changeset for the .csproj listed a branch and a merge as pending changes by me
File -> Source Control -> Open from Source Control, Navigate to TFS project, try to open .csproj in undownloaded folder, receive error "The selected file cannot be opened. The project file has been moved, renamed or is not on your computer."
I may be missing other things I've tried, I'll be sure to update this list if I can think of anything.
Besides those listed above, is there any other way to get those 2 folders and their content from TFS?
Try browsing via visual studio command line to the directory and do a:
tf get . /force /recursive
This should forcibly recurse down from the current directory.
You have tried most of the things that I would suggest. A force-get-latest should work if it's a simple case of TFS being confused about what is on your pc.
Are the "folders" in tfs, or in your solution explorer? Folders in the solution explorer typically mirror the real disk structure, but it is possible to get files and folders in a different location in the SE than on disk. This coild mean that the files the solution explorer is referencing are not mapped into your tfs workspace.
I would check the workspace mapping is as simple as possible (no branches or extra unneeded folders etc), close the solution, force-get the latest version of the disk structure from the source control view, and then load the .csproj file in a text editor to check exactly what the project is referencing to be sure that all the files exist and are in sensible places on disk.
I found the problem. I recently added a certain domain group to the TFSProject/Readers TFS group, then explicitly denied access to all rights in those two folders. It seems that although I am in the Contributor TFS group, I'm also a "Reader", so I denied access to myself.
Visual Studio (and possibly TFS) has somehow (I think perhaps during a source control merge) become confused about the path of a project within my solution.
It thinks it is here (example paths for simplicity):
C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj
whereas actually, the project file is located here:
C:\My Projects\ExampleSolution\ExampleProjectCorrect\ExampleProjectCorrect.csproj
I cannot for the life of me get it to recognize the correct location. I have tried:
Removing and re-adding the project from the correct location. An error message comes up saying The project file at C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj could not be found.
Manually editing the .sln file to ensure all references to ExampleProjectCorrect.csproj have the correct paths.
Doing a find in files on the solution directory for both the correct and incorrect paths, to try and track down where studio is hiding the incorrect path.
Deleting the cache directories for VS and TFS
I'm tearing my hair out because I can't recreate the solution as it has near as makes no difference 100 projects in and is tied in to source control with several other developers working on it.
Can anyone point me in the right direction as to where it is storing this incorrect path and/or how to reset it so the damn thing will load correctly?
Go to Manage Workspaces (either through the File/Source Control menu or the workspace drop down in Source Control Explorer)
select edit for your workspace.
You should see, under working folders, a mapping for the source
control directory to the old/wrong project directory.
Select it and click remove.
Close VS and delete the suo file.
It still references the wrong directory. Maybe rebinding might work at this point but I didn't try that. Reload your project and you should be good to go.
Simply deleting the solutions .suo file worked for me.
I was facing this issue after performing a migration from Visual Source Safe 2005 to TFS 2012. I couldn't wait for the "Conversion Wizard" due out in the next couple weeks so I just ran VSSConvert.exe. This took 6 or so years of history and moved it into TFS.. while I didn't get the actual timeline history.. I got a bunch of entries on the same day with the comments indicating the actual check-ins of the history.. not bad.
So after it ran all night (Successfully, yay!), I was having trouble loading my projects just as this question stated. For some reason, a few projects were being referenced to an incorrect directory. I checked the .sln, the .vsproj files, and getting latest, deleting re-getting, adding removing, etc.. I tried everything noted here... even upgrading my workspace, which I'm not sure what that even did.
FINALLY... I deleted the *.suo files and viola. It worked.
I spent a couple hours on this one.
A slightly different solution.
TFS was displaying a non-existing path for a particular Solution. Previously, I had a laptop with a separate D: drive, but now, I just have a C: drive. TFS still thought my project was stored on D:\Project\MikesProject
I didn't have a .suo file to delete, the D: path wasn't mentioned anywhere in my Workspaces (buried away under the File\Source Control\Advanced\Workspaces menu), TFS showed that I did have the latest files in my (no-longer-existant) D: directory, and TFS in VS2013 didn't have a "Remove Mappings" option for this project.
But what did work was to simply do a "Get latest version" on the project.
After doing so, a fresh copy of the code was written to my C: drive, and (interestingly), now the Local Path was shown underlined.
Previously, the D: path wasn't shown like this.
Odd. Very odd.
We've had similar issues with moves and renames.
Deleting the local directories and then getting again solved it.
Even after deleting the .suo file and .vs folders, I had to edit the .sln file and remove the old relative url from SccProjectName# despite the SccLocalPath# being correct. Apparently VS also uses the name as a hint path.
Try to delete or rename .suo file (including extension). This file is at the same location where your solution file is. It worked for me.
Just guessing, but perhaps some of your other projects references your project from the wrong location? In this case, you have not just to delete and re-insert the project into your solution, you will also have to delete and recreate the references from the referencing projects (stored in their .csproj files).
After trying many recommendations I deleted the suo file ( again ). The last time worked. Why it did not work earlier I do not know. In general I find deleting the suo file one of the first steps I do.
I had my asp.net website solution opened from my Dev Branch.
Then for some other purpose I opened same solution from Main branch.
I made a change to one of my .ascx.cs file in the dev branch and set breakpoint. When I ran the debugger, all my break points were hit in the Dev Branch except for the .ascx.cs which was hitting the Main branch. Have not idea.
Tried cleaning the Temporary folder but didn't work.
What worked:
Closed all instances of Visual Studio
Opened the solution from Dev branch again.
Run again and the break points started hitting.
In my case i copied the *.sln file into the project folder and changed the path to project into the *.sln file. Only this resolved the problem (vs 2015 sp1, winservise project).
Delete *.suo does not helps for me.
Yet another solution worked for us - after trying the delete of suo and almost everything mentioned in this thread. We had a project in the solution which was showing a ghost version of the csproj file. We deleted that file and our paths fixed on another project we were trying to add.
Deleting obj and bin files would solve the problem...
I know it is an old line. I just went through the same problem. We recently migrate the TFS, so I created a new workspace to map to new server and kept the old one. Every time when I open a solution which is supposed to target to my new workspace, VS always tried to load projects from my old mapping directory, till I removed my old workspace.