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.
Related
Today, while trying to publish an app so I could test it, I suddenly got this error message:
The item
D:\ScratchSrc\TryNewReportViewer2017\TryNewReportViewer2017\TryNewReportViewer2017.csproj.vspscc
could not be found in your workspace, or you do not have permission to
access it.
That's a mystery to me, as I've never gotten this before and I was working with this app just last week. Publishing it, too.
I've looked for the .vspscc file. Found it exactly where it said it should be. So, the alternative is that I don't have permissions to it. I don't understand why I shouldn't have permissions to a file on my machine that I created, but whatever. So, how do I get permissions to my own file?
I'm working with VS 2017, TFS 2015 on premise.
This issue may due to the wrong source control binding for that specific xx.vspscc file.
Double check your source control bindings for that file in TFS. You could also try to unbind and rebind the file.
Then delete the file in local(back up local changes first) and get latest version from TFS. Finally do the publish again.
If above solution is still not working, try to delete local workspace and create a new one, get latest version of the file, modify the file with local changes (if you have) in your backup , check in the file, then do the publish .
Another reason for this problem is, that the vspscc file is not checked in.
Just do a "Compare" on the project folder to see, if it's missing.
If the csproj.vspscc is missing you can create a new one by removing the project in visual studio and adding it back
I was able to 'fix' the problem by going to the source control explorer, selecting the smproj file (which was checked out for editing), and checked it in by itself. Then, I checked in the Model.bim. Was able to do both of these things without getting the error.
I also tried all the usual things, deleting the entire solution directory, getting it from TFS again but nothing worked.
Noticed the version of Visual Studio 2019 was a few months old so upgraded to the latest. That fixed it!
Am trying to publish my Web Application. It worked fine literally 15 minutes ago and not aware of anything changing in the meantime. Now receiving this error:
Copying file bin\myApp.dll to obj\Release\Package\PackageTmp\bin\myApp.dll failed. Could not find a part of the path 'obj\Release\Package\PackageTmp\bin\myApp.dll'.
Tried copying the dll manually and Windows just hangs.
Any ideas?
Usually this happens to me when a file is locked (still in use) by windows.
Try right clicking on the solution and doing "clean" solution. Then rebuilding.
If that does not work. Try cleaning solution, closing Visual Studio, re-opening it, then publishing it.
Think I've fixed it. Had to remote directly into the server and cut the release folder to the desktop then copy it back again. Window's threw some permission errors, which it shouldn't have as I have full permissions but worked when I clicked "Try Again". Then manually inserted the dll the same way and tried publishing again. This time it worked. Bit of a weird one but seems to be working now.
I was looking for a solution to this problem and I've found out, in my case, that the folder was not being created when the project was published in IIS. So I've copied the folder from my project's directory to the location where the project is published.
It worked for me!
I had a similar issue and found that the cause was the permission set in the Build folder located in the project folder where the software is compiled to.
For some reason the permission were not set to full, and on further investigation the delete permissions were not set to active.
This meant that the first compile succeeded, but the second failed because the original folder could not be cleared by Visual Studio, or the original files could not be overwritten.
Setting the permissions to full fixed this issue.
This happened to me when you have a files that the path that is longer than 255 chars.
Ensuring all file paths from the drive root to all the files in the Debug\Package\PackageTmp folder were shorter than 255 corrected the issue for me
I have some tests that were marked as [Ignore], but now, I want to run them again, so I remove the [Ignore] attribute, but Visual Studio still treats them as ignored.
What can I do to clear the cache to not ignore the tests anymore?
Update:
It looks like this data is stored in the vsmdi file:
<TestLink ... name="MethodName" ... enabled="false" />
So deleting the vsdmi file, or otherwise causing it to be regenerated is necessary.
But, visual studio caches it, so restarting visual studio seems to fix the problem (sometimes at least).
We have this issue where I work as well.
You can manually change the .vsmdi file or delete it. If you open the test view again (after deleting it) it will generate a new file.
Also, the same kind of issue can occured with which test settings you have selected. It will 'cache' that as well.
Have you tried Clean Solution (in the build menu)? Also I would try deleting the bin/obj folders from the test-project. If that doesn't work I'd look for other (binary) files that might be a cache of some sort or related to test-projects and just delete them. I can't imagine it to be hard to locate such files and just delete them (make sure you have a backup, just in case).
EDIT Apparently it's the .vsmdi file.
EDIT2 Apparently not :P
If I would've encountered such a problem I might even have done a filesearch looking for specific method-names that have been [ignored]. Make sure you use a tool that looks "inside" every file, windows file-search ignores a crapton of files.
Even while this topic is quite old, I'd like to add my solution to this problem, for anyone who's having the same problem...
I recenlty had this problem also, and found the solution in the .vsmdi file.
Under 'Test Settings', 'Unit Test' a had a folder referred in 'Root folder for the assemblies to be loaded:' and the checkbox 'Use the Load Context for assemblies in the test directory' was checked.
I unchecked the checkbox, and after that, my tests did run succesfully! (I knew the files referred in 'Root folder....' where old assemblies.
You can also remove the files from folder in 'Root folder...' to make sure your old assemblies are removed.
I was using Visual Studio 2012 and did not have a .vsdmi file but ran into the issue. I was able to solve this by deleting the .suo (hidden file next the .sln file) file and restarting the Visual Studio. I know it says without restarting but the provided solution didn't work for me so I am providing an alternative in case someone else runs into the same error.
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.
My solution structure looks something like this:
MySolution
FirstProject
SecondProject
SolutionFolder1
SolutionFolder2
SolutionItem1.txt
SolutionItem2.txt
Then there are two workspaces with
this solution at the same version
used by two users on different
computers.
A solution item is removed in the first workspace and the change is checked in into TFS.
In the second workspace the latest version is get from the TFS (the workspace is without local modifications and no files are checked out). Visual Studio displays this message:
Your action caused a check out of the
file(s) C:\MySolution \MySolution.sln,
and a new version from source control
has been loaded in the development
environment.
Now, there are two items in pending changes in the second workspace: solution file is checked out and the solution item is deleted. After undoing these changes and getting latest version, they appear again. These conflicts are resolved only during checkin which is a little bit confusing.
Is there a way how to get rid of this TFS oddity? Thanks.
I cannot find any answer but there is a workaround. Solution probably is not the best place to store complex folder hierarchies with a lot of files. When these folders and files are moved to own VS project then everything works well.