I have a ASP MVC project committed to SVN (used Visual SVN).As the project grew up i kept adding files.Most of the time when i "Get" project everything is available in VS2012. But today when i get the complete solution from repository - some of previously added files(cs and cshtml and respective folders they are in) are not included in project solution in VS explorer but they are there in the Directory that i did get from svn-
My Project in SVN~
MyMVCProj
ModelFolder
ControllerFolder
ViewFolder
view1folder~hasfiles
Now i add a new folder to viewfolder with files within and commit
MyMVCProj
ModelFolder
ControllerFolder
ViewFolder
view1folder~hasfiles
view2folder~hasafile(<=This available in my disk after getting from svn not in VS2012)
what am i doing wrong? I do get project everyday by >Visual Studio2012>VISUALSVN>Get Solution from Subversion;this saves project to disk and opened in VS
I guess that project's file wasn't committed to the repository together with other changes. Here is how you can solve this:
Go to Visual Studio | VisualSVN | Show log and look for the revision committed by DEV2 which added view2folder/,
Take a closer look at changed paths. Most likely the revision added view2folder/ with its contents but the revision didn't change MyMVCProj.csproj file.
The *.csproj file contains information about the files included in that project. When items are added to the project, references to them get into *.csproj file. If the file is missing these references, then you don't see added items in Solution Explorer.
In Solution Explorer, click Show All Files, right click view2folder/ and choose Include in Project.
In VisualSVN's Pending Changes dialog you can see that project's file has been modified. Commit the change.
That's it.
I found solution after some workaround -
When two or more person working on a project this situation may occur. For me it happened because of following scenario:
Dev1 commits projects to SVN,
Dev2 GETs it and does something and even adds files/folders,
Dev1 just updates and starts working. Now the newly created files by Dev2 are not included in project; but they are available on local disk. These had to be manually added to project after update. (Look for related post).
Please Update here if my approach is wrong.
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)
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.
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.
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.
For one of my ASP.Net site I use AnkhSVN to commit to a VisualSVN Server with a post commit hook to update the live website.
This setup works great for every directory EXCEPT the Bin directory. When I build my solution the dll is placed in the site's /Bin but does not show up in Pending Changes. If I select the dll, right click -> Refresh Status, right click -> Commit... it will be committed, but I cannot commit the dll's in the /Bin with the rest of the site.
What am I doing wrong?
Visual Studio does not regard the dlls referenced in the project, as source. Thus they will never be checked in, only copied to the bin folder when the site is built.
VS uses the .refresh files to know which dlls are referenced (the content of a .refresh file points to the original dll), and these refresh files are regarded as source and will be checked in. So to make your setup work you will need to build the project before deploying the site.
Imo this kind of task belongs in a build system, like CruiseControl.Net or TeamCity, not in a svn post commit. You can easily set up such a system to monitor your svn repository, have it compile the solution and then, upon a successful build, publish to the live website.
Actually, I would advice against automatically publishing directly to a live website without first publishing to a staging server for test. But you could have your build system do that too.
Check if the files in your your bin folder are even under version control (you can do an svn add if not). Another possibility is that the files in the bin directory are being ignored by subversion. In that case, you'll have to remove them from the ignore list.
AnkhSVN doesn't look for libraries and some additional files!
But you can add additional files into SVN in hand mode:
Coose View -> Working Copy Explorer
Find files that you like to add, and click Add:
Press ok!
And now you can see you library in "Pending Changes" window.
Agree with Nader. Perhaps files are not under source control. Also Suggest you dont include the bin files (as they are really build items) in source control. It is sufficient to have the source code under version control and tag it appropriately once the build is done so you can reproduce the necessary binaries as and when required. If you MUST have the built packages tagged and versioned, then you can run svn status on the build workspace -- it will show up all the files not yet included under source control and you can write a small script to add them all after.