My TFS workspace is at C:\Users\...\MyProject, which I have mapped to X:\ using Windows subst command. In my Visual Studio 2010 solutions, this works fine for most of the projects. Only 2 of them are always linked (absolutely!) wo the C:\Users\... path, no matter what I do.
I tried:
Removing and re-adding them, obviously.
Removing the explicit absolute mapping for those 2 projects in my workspace settings. It is re-created as soon as I add the projects.
Manually twiddling in the solution file with Notepad. Makes the source control binding invalid, and 2.'s explicit bindings are re-created when I rebind them.
Some help would be very cool. I'm stuck for several hours only dealing with source control...
Cheers
Matthias
P.S. Some might wonder why I do the subststuff: As the project directory names are pretty long, the often exceed 260 characters, which makes many features in the VS/.NET environment stop working.
Related
Me and a friend are working on a Unreal project and we're using GitHub for our source control (with GitKraken).
I have created a few branches to keep work isolated. Just to test merging, etc. I created a class in my Programming branch and swapped branches just to see if the files didn't somehow go to all branches (just wanted to make sure I set up branches correctly). Luckily, the files don't go across branches.
However, I did notice in Visual Studio, the class files are still appearing in the Solution Explorer but they are not in the projects directory on my computer. I have Googled around and most people are saying about 'Reloading the solution', but I see no option to Reload the solution. I've tried re-building, compiling to see if the files go after compiling, tried tinkering with some options, including the .sln file in the commits (removed .sln from the .gitignore) and nothing seems to be working. I'm trying to work out how to stop visual studio from showing files in the solution explorer if they're not physically in the project. Just to avoid confusion when switching branches.
Any ideas?
I have a peculiar problem where all but 1 of my projects are showing the Mercurial plug-ins for my solution correctly.
All the projects have been committed in my mercurial repository already.
The icons for the problematic project actually shows up correctly in another solution that includes it.
Fixes I've tried so far:
Recreate the Solution file from scratch.
Remove/Add Project again.
File compared csproj & sln files between the working and non working solutions.
I'm using Visual Studio 2015.
Has anyone come across this problem before?
It turns out I had to delete the hidden directories under the project folder that pertains to a different source control system (.svn).
It seems like the Mercurial add-on and/or Visual Studio gets confused if it sees more than 1 hidden folders under the project directory.
I was creating a website using visual studio and accidentally deleted that project folder. :(
It was three months project. Is there anyway to get it back? visual studio 2013
Are you using any Source control management system (e.g. SVN, git etc...)?
If so, this is the time for a revert. If not, you should...
Was the project deleted from your disk? If not (it shouldn't..),
just re add it to your solution. Chances are it is still in your solution folder
(You can easily open it via Visual studio).
If it was deleted from your HDD, this is where things starts to get tricky. Try restoring deleted data from your disk.
You will need a software to help you with this task (e.g. this one was randomly selected using a simple google search).
In case nothing of the above works you can take your HDD to a professional lab to restore the deleted data.
If it is just a small project, I wouldn't bother. If it is not, Shame on you for not using SCM ;0)
Good luck...
If nothing of the above works, I am sorry for your loss...
This is kind of a usability question for using VS2005: I have different branches of the same Visual Studio 2005 solution checked out from version control. The solution and project files are also under version control. On my development workstation, I sometimes have multiple instances of Visual Studio opened on a different version or branch each. They all show up under the same name in the window title and the taskbar, which makes it hard to switch to the correct one etc. (The same goes for the list of recently opened projects in the startup page, but I rarely use that, anyway.)
I tried to find a way to only change the name displayed while not running into too much trouble with source control, but Visual Studio 2005 seems to take the solution name from the name of the SLN file itself, not from some attribute inside of it.
It would already help to have Visual Studio show the full path to the solution file in the title bar, but I haven't found a way to do that, either.
How do you handle different versions from the same solution?
Use the (free) VSCommands plugin:
http://geekswithblogs.net/deadlydog/archive/2011/04/29/friendly-visual-studio-solution-names-for-branches.aspx
I guess it only works when using different folders for different branches (not SVN switching), but still, it's good stuff.
Same issue here. VS has bad support for equally named solutions in different directories.
A somewhat hacky workaround: http://www.helixoft.com/blog/archives/32
There's an ideal extension for your problem, but you must use at least VS 2010:
http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6
It changes the title bar, so must not rename solutions or files.
I know that is an old post, but perhaps you have now a newer VS version :-)
Why don't you rename the solution file on your branches, e.g. MySolution-branchXY.sln?
Update:
I'm not sure I understand your comment.
As soon as you have branched your solution, you have two independent versions of each file: one on the trunk (or source branch) and one on the new branch. The two files simply share a common history, but you are free to change them independently on both branches. So you can rename the solution in your branch.
I'm trying to use Visual Studio 2005 with ClearCase eclipsed files (view private which "eclipse" a versioned file), but any time I save the file in VS, it becomes uneclipsed, and returns to the versioned file. In Linux, I use VIM instead of Visual Studio, and get around this problem by setting backupcopy=yes, thereby forcing it to save files by writing to a new file and then copying the new file over the existing one, instead of moving the original file out of the way (which undoes the eclipse) and then writing a new file, but in Windows, I'd like to use Visual Studio (since the tree also includes C# code compiled under VS). Is there any way to teach it to save files this way?
I do not think Visual Studio does save file in a particular way that may cause the file to be first removed, then written.
Considering that, with developer's environment as Windows with Visual Studio, eclipsed
files often happen just by writing a file case sensitive and later not case sensitive.
Hence, did you check the case of your file ?
Could you also check the config spec associated with your Windows view ? (and compare it to your Linux view).
I just spend 1/2h with a Visual Studio 2005 / ClearCase / dynamic view and... I do see the same thing!
The only workaround I can fathom is to add a non-selection rule:
element /my/private/file -none
That way, even though VS2005 remove then add the private file when saving it, ClearCase does not try to restore the versionned file, since it is not selected at all.
Si, the answer may not reside within VS2005 (I studied the options without seeing any obvious setting altering the saving process...), but rather within ClearCase.
Let me know if it helps.
As noted in the comment, the downside of this approach is "un-eclipse" can no longer be a matter of moving/removing the private file to let ClearCase dynamically restore the versionned file.
Now, that step must be complemented with another one, which is to comment the non-selection rule in the config spec.
If anyone is still reading this... I just discovered that Visual Studio 2008 appears to work just fine. Go figure...