I just noticed that my .sln, .vssc, .csprog and my entire root of my main project is missing from TFS latest changeset and when I try to load or open the solution from the server, those files mentioned are missing so my project is screwed up now. how can I recursively restore all files including the solution and other files mentioned?
Related
I cloned the whole source code of roslyn from github.
When I open a solution, like Roslyn.sln or Samples.sln, many projects couldn't be loaded and I get an error displayed in the output window for every project that couldn't be loaded.
Error:
The imported project "BASEPATH.nuget\packages\Microsoft.VSSDK.BuildTools\14.2.25201\build\Microsoft.VsSDK.BuildTools.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. BASEPATH\Source\Repos\roslyn\build\Targets\Settings.targets
I use VS 2015 U2 enterprise edition.
I hope that there is somebody that can help to get the issue fixed.
You have to run the Restore.cmd script in the root folder before you can open in Visual Studio. You should read our instructions for building.
Simply copy a roslyn file out of one of your other projects and past it in your bin folder clean and rebuild and you will be all set
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).
I am using Visual Studio 2010 to develop an MVC 3 application for Azure. We are using AnkhSVN for subversion control, which has been slightly buggy in the past.
The error I'm getting when I try and Build/Debug my application is:
Unable to copy file "C:\Xxx_bin_deployableAssemblies.svn\all-wcprops" to "bin\.svn\all-wcprops". Access to the path 'bin\.svn\all-wcprops' is denied.
The story gets more convoluted, since this error is not thrown on another one of our developer machines, just on mine. The only real difference in our machines is that I have SP1 installed on mine.
Also when I updated AnkhSVN and re-checked out the app from the subversion server it work without throwing an error for the first build. After shutting my comp and then starting back up there error popped back up again.
Update:
I still haven't found a real solution. I just delete the .svn file in the folder and that takes care of the issue with Building the app. However, when I update or commit it throws an unversioned error.
I think the problem is that the app is trying to copy the .svn file over during the build, instead of just ignoring.
Do you know of any way to have the .svn file to be explicitly excluded from the build?
I need to resolve this issue asap, so any help is great!
Thanks
I received the same errors after I versioned my MVC 3 app for Azure on VS 2010 SP1. I was able to resolve this issue in three simple steps.
1.) From the VS 2010 Solution Explorer, click 'Show All Files'. This will show the hidden 'bin' and 'obj' folders in your Web/Worker role project. Right-click and delete both 'bin' and 'obj' folders.
2.) In Windows Explorer, browse to the folder that is versioned (should be your root solution folder). Right-click -> 'SVN Update'. This will download and put back the 'bin' and 'obj' folders that you deleted in VS. This is necessary because your project will exclude these folders from the solution, however SVN will still think they are part of it.
3.) The final step is to delete these files from your repository. In Windows Explorer, browse to the project that contains the 'bin' and 'obj' folder. Select the 'bin' and 'obj' folder -> right-click -> TortoiseSVN -> Delete. Go back to the root versioned folder and SVN commit to remove them from the repository.
The next time you build your Solution, the 'bin' and 'obj' folders will be recreated. Just make sure you don't add or commit them to your repository.
I fixed this problem by going into Windows Explorer and changing the properties of the folder to not index (look in advanced settings) and then manually copying the files giving me errors.
I had the same problem and fixed it.
You have your build output checked into SVN. This Azure target (that's complaining) should only be messing with \bin, \obj directories during a build. It will be cleaning and building. This clashes with .svn as source controlled files under .svn have hidden files and folders with read-only access. Therefore the build runs and subsequently breaks when the Azure targets try to delete/move the .svn files.
To fix just remove your build output from SVN (anything in \bin or \obj). You should not be placing these files into source control anyway as the rest of the files in SVN produce this output, so there is no reason to save it separately. Then you can delete the bin/obj etc folders and you should no longer experience the issue.
If you just delete the bin and obj files as other people have suggested then you're just leaving the problem for the next poor sucker that checks out a clean.
I had the same problem. It appear that the project bin folder was "accidentally" also committed into the svn. After removing the bin which of course shouldn't be in the svn the problem was solved.
Now it is still needed to understand why the build try to copy the sv folder to the bin.
Somehow another application keeps the file locked while Subversion (below AnkhSVN) tries to replace it with a different version.
Usually this is caused by a virus or index scanner. Retrying a bit later usually resolves this issue.
Sometimes a Subversion "Cleanup" (Solution explorer->(relevant node, E.g. Solution)->Subversion->Cleanup) is required to recover from similar errors.
I also had this problem. The cause for me was that I had created the bin directory myself instead of letting VS create the bin directory. Once I deleted the bin directory cleaned the build and did a rebuild, everything worked fine.
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.