In Visual Studio, I moved a few files and folders around.
When I try to check my project into my repository on VSTS, I'm getting an error that reads as below and fails to check my project in.
"Could not find a part of the path..."
Looks like the issue has to do with those files/folders that I moved around. Funny thing is I did all that inside Visual Studio, hoping it would understand what I was doing and not give me this error.
Basically, the folder that VS is not finding is a folder that I moved to a new location. So it should see it as deleted in its old location and new where it is now.
Is there a way to mark a file/folder as deleted? How am I supposed to fix this error.
Related
I have been getting errors in my previously functioning Visual Studio solutions.
These are stored on a network drive synced with the My Documents folder.
The error is:
"The project file '\\myfiles\users\myfiles\users\rgorr\My Documents\VSProjects\FMS\FMS4\FMS4\FMS4.vbproj' has been moved, renamed or is not on your computer."
And that's indeed the wrong directory. \myfiles\users\ is duplicated in the path.
However when I open the SLN file in notepad I see that the directory is "\\myfiles\users\rgorr\My Documents\VSProjects\FMS\FMS4\FMS4\FMS4.vbproj", which is correct.
If I try to edit this in the "File path" field in the properties window of the project that failed to load, I get an error: "Not implemented (Exception from HRESULT: 0x80004001 (E_NOTIMPL))"
If I remove the project from the solution and re-add it, it will work. However once I save the solution and reload, it gives the original error.
Does anybody know what's going on here? It's been an issue with most of my solutions ever since migrating to a new laptop and grabbing them off of TFS. It persists in every version of Visual Studio I have installed.
I just deployed an asp.net mvc 3 web application to AppHarbor but it failed:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3932,5): error MSB3541: Files has invalid value "<<<<<<< HEAD". Illegal characters in path. [D:\temp\q5cmde4m.uk1\input\MyProject\MyProject.csproj]
This happened after I opened the project with Visual Studio 2012 (the application was created with VS2010).
Try to search the entire solution for the value and remove it from where it occurs, and then delete the obj folder from your project. When you build again it should work.
The obj folders are hidden in Visual Studio. You can see them with a file explorer.
Delete the obj folder within your project and it will fix the issue.
though it is very old question but I would like to add an answer here.
when you work with multiple developer in visual studio you should git ignore obj folder, .suo,.sln etc which is only holding the visual studio information user based.
refer to this SO question
Ok this might be helpful to someone else.
in my case my .vbproj file and some form files somehow had the last lines of its code truncated, I fixed this by restoring this missing part of the code (around the last 10 lines were missing) from a previous backup of the same project.
The other files got corrupted in a simillar way and were fixed by restoring the missing parts of the files from the backed up ones on a text editor (notepad)
After getting this the project loaded without issue.
Delete both obj and bin folder it will fix the issue, which in my cas its been done and it was causing when create pull request from remote repository !!
Yes, it is about merging conflicts. Usually Visual Studio highlights most of the errors with file paths. However, it does miss some files.
All you have to do is REMOVE the "obj" an "bin" folder from your solution.
If you are in Visual Studio, you have to select "Show All/Hidden files" as "obj" folder is hidden, and then delete it.
You can also delete it by going to your directory where your project is stored e.g C:/Users/username/source/repos/project/ (can be different in your case).
We are using TFS 2010 and facing a problem with deleting a folder inside of a solution in Visual Studio.
In the latest version of checked-in code, the directory in question has files in it.
One of the developers decided to move the files in that directory to another location within the solution. He then tried to delete the old folder but go the following error:
This operation cannot be completed.
You are attempting to remove or delete a source-controlled item where the item is either exclusively locked elsewhere or otherwise unable to be deleted from source control.
Does anyone know what the problem is with trying to do this and is there a way to get around it?
You cannot delete a folder that has pending changes on any of its children (including if any of those children are being moved out of the folder - they're still children until that changeset is checked in.)
You'll have to do this in two steps: first, move the children out of the folder and check those changes in, then delete the folder as a separate changeset.
If the folder you want to delete exists on your local machine, just add a new file to the folder from within the Visual Studio IDE (it doesn't matter what type of file). Then you should be able to delete the folder from within VS.
If the folder was deleted from your local machine, create a new one with the same name and then follow the above steps.
I created a C# project and added it to source control (mercurial). I can edit files in VS, commit it and push it using TortoiseHg. It goes to the server. When some one pulls they get the files.
In my visual studio I added a folder and a file inside that folder. I used TortoiseHg and it saw the new file in the new folder. I committed it and pushed it.
However, now someone pulled the latest code from the server - and they got the new file (it is visible through windows explorer), but when they open the solution in VS, they don't see the file.
Does someone have an idea what is wrong here? or things I should check? Thank you for the help.
P.S. I have visual studio 2010 express (so I can't use the VisualHg plugin).
Visual Studio caches changes to the solution and project until an explicit save or a build. In your comment:
In my visual studio I added a folder and a file inside that folder. I used TortoiseHg and it saw the new file in the new folder. I committed it and pushed it.
I see that an updated .sln or .vcproj file was not mentioned and checked in. Did you see an update to either of these files via TortoiseHg? If not, make sure to build or save your project after a change like this.
Did you make sure that the Visual Studio Project File or Solution file is being updated and committed?
VS solution contains projects and each project select managed files by metadata(***.vcproj file). It's not the way include all files from root directory.
So, your co-workers can see new added files by in following two ways.
1) share project file(***.vcproj)
2) manually add files in each person's VS instance.
After some use Visual Studio 2008 when opening a solution that is checked into Visual Studio Team Foundation will pop up a dialog saying:
Projects have recently been added to this solution. Do you want to get them from source control?
This happens every time the solution is loaded (even if no projects have been added). The only way I have found to remove this minor annoyance is to completely rebuild the SLN file.
Has anyone found a better/simpler way?
I had this recently after we moved a number of projects in the solution. I worked out eventually, that each project actual appears in solution file multiple times each with path information! So even though the path in the main reference of the project was correct it was wrong further down the file.
So go through the .sln file and make sure the paths in all the references of each project is correct.
For instance, the first reference for one of my projects is:
Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "ObexPushVB", "Samples\ObjectPush\ObexPushVB\ObexPushVB.vbproj", "{E3692A59-D636-48E8-9B57-7DA80A88E517}"
EndProject
In my case the path there was correctly updated. But then we have also for that project:
SccProjectUniqueName8 = Samples\\ObjectPush\\ObexPushVB\\ObexPushVB.vbproj
SccProjectTopLevelParentUniqueName8 = InTheHand.Net.Personal.sln
SccProjectName8 = Samples/ObjectPush/ObexPushVB
SccLocalPath8 = Samples\\ObjectPush\\ObexPushVB
So all of those paths needed to be updated too! After I fixed that manually all was well. (The sample there is after the fix BTW).
Hey, this actually happened to me about 4 years ago.
First, it sounds to me like someone on your team doesn't have all the updates applied to their visual studio installation. Go around and get everyone upgraded to the latest service pack for your VS version.
Once that is done, unbind the solution, fix the file, rebind it and tell everyone to do a force get latest on your TFS project.
See
http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/c2822ef1-d5a9-4039-9d3e-498892ce70b6
http://www.nivisec.com/2008/09/vsts-projects-have-recently-been-added.html
(broken link: http://technorati.com/posts/Yadz3Mj1pxHPSJLlnUs1tL1sIwU5jXa5rNBbIAnYdvs%3D)
This message will also occur if your solution has a reference to a project whose location is outside of the solution directory, but it doesn't physically exist (i.e. you hadn't checked it out before opening the solution). VSS (or TFS) will then give you that message and clicking OK will automatically get latest on the project that's missing so your solution won't have any unloaded projects in it.
EDIT:
Reading that again confuses me. Basically you get the message if your solution has a source control binding to a project that isn't inside of the folder your solution is in, and that outside project doesn't physically exist on your machine. Clicking on OK will check the project out for you.
In my case it was a reference to a test project which has been deleted.
I noticed that when I inspected all the projects in the Solution Explorer. Our team uses solution folders so it was not normally visible and because it was a test project it didn't have any impact on the application.
After removing the project from the solution the messages is no longer shown.
I'm working with Visual Studio 2013.
For me, it happened after having modified the folder's structure of my solution (I added a sub-folder for a project directly on the source code explorer). I got rid of this boring error by removing all the projects from my solution, using the solution explorer. After that, I closed Visual Studio, manually edited the .sln file and removed the whole section :
GlobalSection(TeamFoundationVersionControl) = preSolution
To finish, I just added the projects back to the solution as "Existing projects" with solution explorer. Visual Studio will recreate by itself the removed section of the .sln file.
The same error message can occur if someone adds a project, check-in edited solution file, but don't adds project directory to source control.
To cut a long story short - this error can mean that in .sln file there's reference to .csproj file, but the .csproj itself is physically missing.
In my case I renamed a(n) (unloaded) project in VS. It correctly moved the project to a new folder and no data was lost. However the solution file still pointed to the old directory which still existed but was empty (so the project could not be actually loaded).
After deleting the project from the solution (which was no problem because the folder was allready empty) the problem was solved.
Adding the project again from the new location was no problem either.
I had this problem after moving a number of unit test projects that were under source control (VSTS) into another folder. After this whenever I opened a branch I would get the "Projects have recently been added to this solution. Do you want to get them from source control?" error.
For some reason the csproj file from the trunk wasn't under source control which meant it was missing from the branched version. I find this happens sometimes after moving source controlled projects.
To fix it I opened the original source trunk, used Source Control Explorer to add the missing file(s), then merged the trunk to the branches to copy over the missing csproj file.
After this I could open the branched versions without the warning popping up.