I'm using Visual Studio 2012 and TFS, and I needed to move my folders on my local machine which was mapped to a different directory. When remapping, I was having problems where the folder mappings were getting messed up badly as you could see in "Source Control Explorer" in Visual Studio.
As part of my attempts to fix it (after hours of trying), I removed all folders from the Workspace and removed all folder mapping from the root with recursive checked so nothing would be mapped and no local folders in workspace. However a few subfolders in TFS still show their Local Path setting when viewed in "Source Control Explorer".
To make matters worse, when I try to "Map to Local Drive" in order to remove the setting, it says "The server folder is not mapped". So it says it's not mapped but shows that it's mapped.
I've tried remapping the root again with recursive checked and the prior local path settings stay the same and the Workspace only shows the "root" as mapped.
As a side note, I do have multiple servers that I have to connect to in case that matters.
I'm unable to remove mapping on the folder, what do I do? Does anybody have any ideas?
I was able to get it to work.
The way I did it was by removing all mappings in the root as the original question stated, but for those folders that maintained local paths, I just mapped to a valid directory where I wanted them to be instead of the old path.
While doing this Visual Studio crashed (i'm sure that never happens). I then restarted Visual Studio and then went back to the previous folders with the recently changed mappings and then removed mappings. When I did this, it removed the mappings and said "not mapped". I did this for all the the folders that were messed up.
After all folders were un-mapped, I mapped the root to where I wanted with recursive checked and the problem folders from before were mapped to the new directory.
I think the key was that I had to remove the mappings at the root and then remap the folders and then un-map them again. Throw in a little "designed" crash by Microsoft's Visual Studio (sarcasm intended) and it worked. Thanks for those that provided help.
There is a remove mapping option if you right click on the project and go to advanced.
Have you tried using Team Foundation Sidekicks to view your mappings? You can find all the working folders in your workspace and delete them.
If that doesn't help, try creating a new workspace.
Related
I am having problems adding files to TFS Online. Here are the steps I made to get up to this point:
Created a project in TFS "SomeProject_Classic"
Mapped it to a path in my computer C:\SomeProject\classic
Pushed all files from from WITHIN the \classic folder to this project
Deleted the project in TFS
Recreated a new project in TFS with the same name ("SomeProject_Classic")
Mapped it to a path on my computer C:\SomeProject
I try to add the classic folder (not only the files in it like step 3, but the entire folder itself)
On this last step, it gives me the error "The item $/SomeProject_Classic/classic/somefile.txt already exists".
Basically, I think it is having a problem thinking that I have already added these files because I created a project with the same name in TFS and never "checked those files out for deletion" before deleting the project.. I feel like I need to clear a cache or TFS memory or something. Any advice?
Clean the Cache folder on client computer. The folder path is: C:\Users\username\AppData\Local\Microsoft\Team Foundation\６.0\Cache.
Use the tf destroy command to destroy, or permanently delete, version-controlled files from Team Foundation version control. Check:https://msdn.microsoft.com/en-us/library/bb386005(v=vs.100).aspx
This was somewhat related to Cece's answer in that even though it was deleted on the server, my local computer still thought the file were in the uploaded workspace.
What I did was create a temp folder TempRepo on my desktop and moved the files from the "classic" folder to it. I mapped my workspace to this TempRepo folder. Then I was able to "add existing files" to the workspace and push my files from this temp folder to Visual Studio Online.
When I was done, I just mapped the workspace back to the original folder and performed a "Get" operation. Now I have all the files uploaded onto TFS and the correct workspace set.
I just changed the file name. Fixed it.
Just do "Undo Pending changes" and delete the files and check-in again...problem will be fixed..
I have a workspace in VS2015 (same problem in 2013) that I'm trying to completely remove and start fresh with a copy from the server. To clarify, I want none of the files or changes that currently exist and I want to start completely fresh with the server copy of all files. I don't know how to correctly do this, however. I've deleted the workspace, the actual files that the workspace pointed to, and I've cleared the cache locations below, but VS still shows that the workspace exists and won't fix itself. In fact, it still shows the mapping even though I've triple-checked that it's deleted.
I'd like to avoid using devenv /reset since I'm pretty customized and I don't want to fix all of it, but I'll do it if it's unavoidable. How can I accomplish this?
Locations cleared/deleted:
%LocalAppData%\Temp\<all VS files/folders>
%LocalAppData%\Microsoft\Team Foundation
%LocalAppData%\Microsoft\VisualStudio\<version>\ComponentModelCache
On the window where you can get a specific change set from TFS, get the changeset with id "1". This is the situation just before the project was created - empty!
Right mouse om project node in solution explorer
Source Control > Get specific version
Version type "change set"
Input change number "1" (without quotes)
Click "Get"
Thought I saw this question answered somewhere on SO but I can't find it. My solution is properly displayed with its projects in Source Control Explorer, check ins are properly logged and the solution is mapped to my local workspace. (GREEN box)
However below the solution folder all the project folders are displayed again.The local path is not mapped and no check ins are being displayed. This is merely annoying to me but might seriously confuse my team. An hour of searching has turned up no solutions for getting rid of these ghost folders. (RED box)
No local path mapped to these folders indicates that these folders are no longer exist on the machine.
You can correct it via going to Source Control Explorer -> select these missing files -> Undo Pending Changes.
I've recently switched from a Windows XP machine to Windows 7. I use Subversion and TortoiseSVN.
I cannot publish my .NET application in Visual Studio. I get over a thousand errors like this:
Unable to delete file
"obj\Debug\Package\PackageTmp\Views\ViewName.svn\text-base\ActionName.aspx.svn-base".
Access to the path
'C:\Code\SolutionName\ProjectName\obj\Debug\Package\PackageTmp\Views\ViewName.svn\text-base\ActionName.aspx.svn-base'
is denied.
Why is Subversion giving me trouble? How do I fix it?
I disabled the file indexing of my bin and obj folders. But, that didn't work.
I noticed that my folders were read-only. I changed that.
It worked! Publish succeeded.
I believe your issue is related to the default permissions assigned the to C: drive in windows 7 (and Vista).
Open explorer and find the c:\code folder
Right click on the c:\code folder
and select properties
select the security tab
select the user ID "Users"
In the permissions box, tick the
"modify" allow box
Select OK, OK until permision dialog
boxes close
That should resolve the permission issue
I had this same problem, and none of the previous solutions worked. What worked for me was to take the bin and obj folders out of repository. After doing that, I was able to publish.
The most likely cause is a permissions issue. The path in question may have been created while you were running with elevated permissions and hence requires admin permissions to delete. Try running Visual Studio as an admin and see if the problem goes away.
If so then the best solution is to do the following
Save the changes to that directory (check in if necessary)
Delete the repository
Re-check out the repository and ensure you are not running as an admin when doing so
I just deleted the existing folders at the publish destination which then allowed publishing to work. Un-setting read-only didn't seem to work. (Not sure why this started occurring).
What actually works is the solution that Zack Peterson gave? Thanks Zack!
I am writing an application that will automatically remove all of the .SVN folders and files during deployment. While doing so, I was getting the same error as described above.
Once I changed the folder to NOT be Read Only, I was able to delete files and folders programmatically.
My next step is to set the attribute programmatically on NOT Read Only so that I can accomplish the entire installation with the click of a button.
Oddly enough, I tried building an old project with Visual Studio 2010. It gave me the error that it failed due to my access being denied. I tried to remove the read-only off the directory and had no luck.
Although, when I opened it in Visual Studio 2015, it gave me the error that my certificate was expired.
Upon creating a new certificate and rebuilding - everything was fine.
For me, the windows service was running in the background. closing the service from the task manager and then rebuilding the project did the job for me.
If you are being denied access to any specific folder, then it is being used by some other application.Check if any other application is using that path to reference that folder of any file in that folder.
In my case , my application was reference a file inside the bin folder. So every time i publish and delete the old one. error will be thrown that bin folder can not be deleted. access denied.
i went in my application. checked in the refrenced path of each dll, removed the ones which referenced the publish path and BOOM
Issue solved.
My problem resolved after doing:
Close VS and Restart your machine.
Update all your softwares to latest stable versions at Manage Nuget package for solution
Run your test now.
Hope this helps.
Right click on the shortcut you start the IDE from and select properties. Click advanced and click'Run as Administrator'. Worked as charm for me.
I get this error when I try to load a VS 2008 project from TFS source control:
The project file has been moved, renamed or is not on your computer
After I click OK the project says "unavailable".
What is the problem? How do I resolve this? I never had this problem before. Some blogs said to delete the .suo file but I can't locate the .suo file. I deleted the entire project on my local computer so that the next time it opens it will create a new one, but I still get same error.
What typically helps to fix it is deleting the Solution User Options aka "SUO".
VS up to 2013
In the older VS it is stored as a "hidden" SolutionName.suo in the same folder as the main .sln file.
VS2015 or later
In VS2015 the same data was moved to a "hidden" .vs folder under the same folder as the main .sln file.
I just ran into this issue using VS 2013 after renaming a project. Stanley's answer guided me to the solution:
Close VS - delete .suo file - start VS again.
Delete the .suo file in a special way.
Don't have the solution open when you delete the hidden .suo file.
Restart VisualStudio.
Open solution and Add project without error message.
TFS works like most source control packages: It remembers what it has put on your computer so that when you "Get Latest" it only has to get the chnages since your last "Get" instead of having to get absolutely everything.
This has one caveat: If you delete or rename the local files on your disk, TFS won't know that you have done this, and it will still think they are where it left them.
If you then "Get Latest" it will not bother to update the missing files.
You are then likely to get all kinds of "missing file" errors, from TFS and any other tools that look for the files.
To get around it, you need to:
If you think you might have any changes in there that you don't want to lose, copy the source folder on your PC as a back up just in case!
Right click on the project (in Solution Explorer) or folder (in Source Control)
Choose "Get Specific Version" from the context menu
Choose to get the "Latest Version" and tick the option that says (something like) "force get of files already in your workspace", which tells TFS to forget about what it "knows" and get all the files again anyway.
If you have any locally-changed (writable) files, then be careful. There is a second option that will overwrite these, losing your changes. But you have the backup, so you should be safe. It's generally better to tick this option as well to make sure that all your source code is completely up to date. (But obviously only if you don't mind losing any local changes!)
When you OK, this will forcibly get all the files in the project to your local drive, and should correct the problem.
Easiest option worked out for me is:
Right click the project & Remove the "not loaded" or "unavailable" project
Right click the solution & Add "Existing Project"
Though it's well known VS defect, definately we can handle it!
Open the solution file in edit mode
Modify the relative path to match the modified/moved physical path ..
SccProjectUniqueName1 = Source\\Order\\Order.csproj
SccProjectName1 = Order.ApplicationService
SccLocalPath1 = Order.ApplicationService
Also, makesure of correct relative path for the referring project(s)
Project("{asdasd-301F-11D3-BF4B-asdasd}") = "Order",
"Source\Order\Order.csproj", "{E25641BC-C990-40E2-8876-08AE8728F763}"
EndProject
Try opening the .csproj or .vbproj instead of the .sln. What has probably happened is the .sln (solution) file has a absolute file reference (instead of a relative path) to the compoenent project(s). You may need to re-create the .sln, or hand-edit it.
In my case, deleting the .suo file was insufficient. I discovered that my workspace configuration had an error. I discovered and resolved the problem with these steps:
In Team Explorer, "Manage Workspaces..."
Click "Edit..."
Correct the value under "Local Folder"
Finally, delete the affected .suo files per the accepted answer.
I found it easiest to create a new Solution sln file.
Clear out your workspace mappings (File -> Source Control -> Workspaces). Edit the workspace and either clear out all the mappings (more repercussion) or find the one that's associated to this server path. Then open Source Control Explorer and remap. Double click the SLN in Source Control explorer and it should get latest. Not entirely sure what has happened or what state you managed to get into, but with this should get you moving again.
I ran into this issue and was able to resolve it by obtaining the .rptproj files from a co-worker and copying them into my local directory. The project was then able to re-load.
I spent a lot of time for trying solve this problem. I did these steps : rename project, rename namespaces, rename project folder, edit .sln file, edit hidden .suo file. Project loaded but it was unrecognizable for TFS! Finally I found this guide.
If you're using Resharper and TFVC is your version control, follow these steps :
Right-click the project in Solution Explorer, select Rename, and enter the new name
Right-click the project again and select Properties. Change the "Assembly name" and "Default namespace" on the Application tab.
Right-click the project again and select Refactor -> Adjust Namespaces. Accept the changes.
Change the AssemblyTitle and AssemblyProduct in Properties/AssemblyInfo.cs
Delete bin and obj directories in Windows Explorer
Open the Source Control Explorer and rename the project's directory. This will close the solution. Let it be closed.
Open the SLN file (with a text editor such as Notepad++) and change the path to the project (there should be multiple places).
Open the Solution again. Clean and Rebuild the project.
Right click on the unavailable project and edit the project file ... chances are, you will find a hardcoded file path or a virtual one that does not match where you checked the project out to.
Kindness,
Dan
Solution for this
Again rename the project folder
Set specific version & force get in TFS
remove read only & hidden option in the latest folder (not the rename one)
Now you can open the project without any issues
Sometimes, even though you changed .sln and .csproj path, and manually rename, you might forget to check the folder name that contains the project.
It happened to me too. Apparently the csproj files were not checked in when I had created them in my old computer, and so when I downloaded the project from TFS in my new computer, the files were not there.
After checking them in using my old computer and getting them from TFS in the new computer, I succeeded in reloading the project.
In my case, because I modified .csproj file, it changed to .csproj.user .
I remove .user from the end of the file.