I work with TFS 2012 in Visual Studio 2010. I create project. My friend get this version and add folder and check in. After that I get last version . In Source Control Explorer I can see this folder. Also I can see in local folder. But I don't see this folder in Solution Explorer. I have tried to Check out Project.sln, and I see message, that file last version but in solution explorer I'm nothing see. How this fixed?
I think you should execute a Get Latest Version in Source Control Explorer.
After this the Solution Explorer should refresh automatically!
If it won't work, i think you should try Get Specific Version and check both CheckBoxes of the bottom of the Dialog.
But if you use the second Option you have to get safe that you have checked in alle changes, otherwise they are getting overwritten.
Related
I've recently noticed that when I go to make a change which needs a file to be changed, VS2017 (Professional) has started to produce a popup saying:
The file <filename>, which you attempted to edit, is read-only on disk.
Would you like to make the file writeable or edit it anyway?
If I cancel this, I get a message:
The file '<filename>' needs to be checked out before it can be edited.
The file was not checked out automatically because you have disabled automatic checkout
when files are edited in the Source Control options page.
The Source_Control->Plug-in_Selection is set to Visual Studio Team Foundation Server; I haven't changed the Options under Source_Control->Environment; both Saving and Editing are set to Check out automatically.
As far as I know, apart from recently updating from 15.7.4 to 15.7.5, I haven't changed any settings. Is there some setting elsewhere which affects this?
Note, my installation of VS2017 Pro Preview, 15.8.0 preview 5.0, does the same thing and running VS2017 as Administrator does not fix it.
Update:
Visual Studio 2015 has no problem checking out the same files in the same local workspace. That is, if I open a solution in VS2017, edit a file and go to save it, I get the above messages. If I then cancel the edits and try the same thing on the same file in VS2015, the file gets checked out. Hence the problem is with VS2017 and not the files themselves.
OK. After further searching I found a pointer to the answer in this answer. Somehow, my VS2017 instances have gone offline from the TFS server. The menu option File->Source_Control->Advanced->Go_Online sorted things out.
My solution had become unbound from the source control server.
To resolve I used menu options File->Source Control->Advanced->Change source control... Select project or solution without Server Name or Server Binding. Click Bind.
I am struggling to solve a problem with Team Foundation Server (yeah, I should just go with Git, I know...). We are working on a mid-sized solution (<20 projects) and suddenly in my workspace I cannot make check-ins or check-outs anymore. Everytime I try to, I get a very generic error message:
An item with the same key has already been added.
This is either shown in a dialog box, in the output window of Team Foundation Server or at the top of the Team Explorer window in Visual Studio 2013.
I already tried deleting the TFS cache located under
C:\Users\[my username]\AppData\Local\Microsoft\Team Foundation\5.0\Cache
and
C:\Users\[my username]\AppData\Roaming\Microsoft\VisualStudio\12.0\Team Explorer
Cleaning the solution does not help, and neither does restarting Visual Studio. Other members of my team still can do check-ins and check-outs. Also I found that the issue is not only related to this solution (although it was the only one I have been working on the last few weeks). Regardless what project I try to open, I get the same error message from TFS. However, if I choose another workspace and try to open projects from there, no error appears and all just works as usual.
Any suggestions on how to resolve the issue?
I solved the issue (at least temporarily) by changing to another workspace and checking out from there. Here are the steps I went through:
Go to "File"-> "Source Control" -> "Advanced" -> "Workspaces..." and add a new Workspace
Open the "Source Control Explorer" window and make sure you have the new workspace selected in the upper combobox. Note: You may get several dialog boxes with the error message stated above.
Select your solution from the left folder tree and right-click on it
Choose "Get latest version" and the Map dialog will appear. Choose a new folder. Perhaps you could have renamed the original folder and reuse the same location then...
Now make the first check-out and that's it!
I saw this error when we were migrating to new tfs and new Gated build with the same was created for the same branch. After disabling renaming/disabling new build issue disappeared.
Close Visual studio, Delete the ".vs" hidden folder, and try again.
Visual Studio's Go To Definition is disabled and F12 doesn't work. Other commands like Alt-F12 may continue working.
Close the solution.
Delete the intellisense database file for the solution: [solution].ncb or [solution].suo
Reopen the solution.
Optional: Rebuild the solution.
Note that this can also be as a result of disabling database for C++/C#.
In Tools - Options, type "IntelliSense" into the search box, and click on C/C++ - Advanced. In the Browsing/Navigation section, change Disable Database to False, if it is not so already.
After re-enabling, close and reopen to force rebuild.
NOTE: IntelliSense will produce large files on disk (*.sdf and ipch) that should be excluded from Git, for example.
I know the solution has been resolved. However, I encountered the exact same problem. I searched internet. None of the trick works including this one.
Eventually, I figured out. I right clicked on the file that had the problem. I included the file in the project. Isn't that obvious. Actually not, the file has been included for a week. I have been working on that file more than 7 hours a day for the whole week. Up till yesterday 6:20 pm.
Oh, I could not compile correctly this morning. There were tons of syntax error message yesterday. This morning, I was able to compile. Strange. right? Then my go to definition was gone.
Took me a while to find out cs and designer.cs were certainly excluded, but aspx file was.
I solved the problem. Did my figure slip? I don't know.
That is one thing people check. Either yourself, someone else, or system accidentally exclude the cs files without the knowledge. I know it is strange, but it solved the problem. There are weird scenarios in Visual studio. People can present 200 solutions. They work for 99% of time, but not our cases. I just bring one more scenario
I encountered this in Visual Studio 2010.
For me, this solution did the trick
Close all the files.
Reopen the files.
and you are good to go.
This also happens, if Visual Studio has files opened, which are not in the current Solution.
I don't know how I got to this state, where files of a different solution where open as I didn't open them manually, but a quick check of the file path showed that those weren't files of the opened solution.
Therefore, "Go to Definition" was disabled.
I found that I had to remove my TFS mapping:
VS 2010 > open Team Explorer > Drill into the team project > double click source control > right click on the team project in the left pane and do "Remove Mapping" > after everything was removed I manually went to the local folder and deleted any lingering files > back in source control explorer I re-mapped to the same local folder and re-pulled all the code. Now the "go to definition" works again.
Not sure why I had to do this...
Check dll in references which is yellow. Remove it and add again.
I've just had this happen with a CMake-based C++ project in Visual Studio 2019. Everything was fine yesterday, then when I opened it up today all the Go To Definition/Declaration etc options were greyed out everywhere in every file in the project, even for things defined within the same file (and the syntax highlighting didn't look right either). It did work if I opened one of the .cpp files separately on its own (without loading the Project/Solution).
I tried various things including the answers here and telling it to generate the CMake cache again, but what finally fixed it was actually deleting the CMake cache. The Delete Cache option didn't seem to work (all the files were still there on disk, and there was some sort of failure message in the Output window) so I just deleted the entire "out" directory from the project directory (well, moved it somewhere outside of the project, just in case). Loaded up Visual Studio again, it rebuilt the cache again automatically and IntelliSense immediately started working again! I just had to wait 5 minutes for it to compile everything again when I wanted to run the project.
Maybe it wasn't necessary to remove the entire "out" directory, but when I clicked "Open in Explorer" under the "CMake Cache" menu it opened the actual build directory (which was the only thing in the "out" directory anyway) so I assumed the entire thing was related to the cache and was getting too fed up with it to try to narrow it down further. It's probably only certain files within that directory really.
Tried all the above solutions in my VS2019, nothing worked for me. Than I've noticed an update sign on the bottom Right corner. After updating the VS all options were restored.
Simple just check your bottom left corner of Visual Studio if Restricted turn it as a trusted and your problem will solve.
In my case due to my project is mapped with TFS so I am unable to go to definition also my project files showing read only when opening from Solution. So I have move to my root folder mapped with TFS and then right-clicked on folder > Go to properties > Attributes section was Read-Only I have unchecked it and clicked Apply. Reopen visual studio. Everything is now working fine.
I faced the same Issue in my Visual Studio 2019 version.I followed the below Steps:
Go to references folder in the solution.
Click on Manage Nuget packages.
Click on Browse.
Search for 'Microsoft.Net.Compilers'.
Click on Update.
This Worked for me.
In my case, another Visual Stuidio was opened (not closed succsessfully). Close all examples of VS, then re open solution.
Just open the Solution using Windows Explorer, instead of opening it from inside VS...
I see a file in pending changes window. I try to compare it with latest version and I get an a message 'The files are identical' If the files are identical why is this file showing up in pending changes window? What changed about this file? Can I configure TFS not to list files that are identical?
This is normal if a file becomes automatically checked out due to a change, and if ultimately the contents of the file are changed back to it's original state. At that point you would see the message about identical contents upon comparison.
This blog entry describes a not-so intuitive way of dealing with this; and in the comments there is an even better suggestion on dealing with it through the command line via TFS power tools.
TFS pending changes ignoring identical files...
Recently I just updated VS2010 to VS 2013, and this issue even worse.
When you use compare, files that are identical don't pop up at all. I hate this because you could not figure out which files are truly changed until you check the compare files carefully.
Finally I figure out a workaround for this:
Add "Undo unchanged checkouts" in the external tools:
Command: tfpt.exe
Arguments: uu . /noget /recursive
Initial directory: $(SolutionDir)
After running this command, TFS will automatically undo all the redundant changes in the files.
But these files still keep check out status, actually they are already undo and same as the latest version. I think It is a bug in TFS. You just need click Refresh icon in the toolbar under solution explorer, these files will be refreshed and show the correct status!
To make the above explanation clearer:
Install TFS Power Tools using the NuGet package manager in VS.
Open the Visual Studio Command Prompt (also called Developer Command Prompt for VS 2013/2015) from Windows Start.
Navigate to the root location of your local workspace through the command prompt.
Execute this command: tfpt uu . /recursive /noget
Choose to discard redundant changes if prompted.
Worked for me.
Further:
Sometimes I have found I need to run the command on the opening prompt of the Developer Command Prompt (and getting a workspace not found error), before navigating to the workspace folder and executing there. If I go straight to the correct folder, the command is not found. (I wouldn't mind a solution to that issue in itself.)
I solved this by clicking the Stage All button in Changes then unstaging them with Unstage All.
It resolved the unchanged file I had in my Changes section. Nice and simple.
Visual Studio 2012 introduced a new concept called Local Workspace.
When the Workspace Location is configured to be Local, then it will place a local copy of the original file (Just like SVN / CVS).
It will then automatically hide unchanged files from pending changes.
Use the TFS Source Control Explorer to "Edit..." the TFS Workspace, and change the "Advanced..."-setting Location from Server to Local.
For me, reconciling the workspace resolves these invalid pending changes:
Team Explorer -> Builds
Right click on latest build with you changes -> "Reconcile Workspace..."
Note: I saw "There appears to be a discrepancy between the solution's source control ...." , but this doesn't apply, as I wish to fix this without changing the .sln file.
For some reason, any time I open a solution which has in the sln file:
SccTeamFoundationServer = http://servername:8080/tfs/defaultcollection
SccAuxPath* = http://servername:8080/tfs/defaultcollection
My copy of VSS insists on switching it to
SccTeamFoundationServer = http://servername:8080/tfs/
SccAuxPath* = http://servername:8080/tfs/
Saving these changes does fix everything for me, but everyone else using the same version control server is fine with the 1st version but not the second version. I wish for my computer's version control server/paths to be consistent with that of my coworkers.
Everyone is using Visual Studio 2010 with Visual Studio 2010 Team Explorer.
I had this problem with a Solution containing *.vcxproj project files, that were previously migrated from VS2008 to VS2010.
The path to TFS was defined in both the .sln file and the .vcxproj files.
The simplest fix was to update the *.vcxproj project files to use the SAK keyword.
ie update from the format:
<SccProjectName>$/MyProject/Directory/abc</SccProjectName>
<SccAuxPath>http://servername:8080/tfs/defaultcollection</SccAuxPath>
<SccLocalPath>.</SccLocalPath>
<SccProvider>{11111111-1111-1111-1111-111111111111}</SccProvider>
to
<SccProjectName>SAK</SccProjectName>
<SccAuxPath>SAK</SccAuxPath>
<SccLocalPath>SAK</SccLocalPath>
<SccProvider>SAK</SccProvider>
Have you tried connecting to http://servername:8080/tfs/defaultcollection instead of http://servername:8080/tfs/ in your Team Explorer settings - Team Project Connection? Try to do that, let someone who have the http://servername:8080/tfs/ version check-in, remap your local instance then get latest.
I just had this exact problem. I finally solved the issue by disconnecting from TFS and reconnecting:
In Team Explorer (View-Team Explorer), right-click on your TFS server name and click 'Disconnect'. Then click Team-Connect to Team Foundation Server...
I did not have any pending changes when I did this. I would check in your code or at least shelve your changes before doing this to decrease the chance of losing work.
The computer that this happened on had been working fine for over a year, but I guess Visual Studio somehow cached the name as http://servername:8080/tfs/ instead of http://servername:8080/tfs/defaultcollection and disconnecting and reconnecting to TFS reset VS to the correct path of http://servername:8080/tfs/defaultcollection. On my server (and I would guess on everyone's) http://servername:8080/tfs/ and http://servername:8080/tfs/defaultcollection point to the same thing. Raymund's solution didn't work for me - I had the same problem that Brian had with it.
Using Visual Studio you can solve this problem by unbinding and binding the solution and/or projects. Try this:
Open the problem solution in VS (did this in VS2013 just now)
Commit anything you need to commit (let's keep it simple - nothing to merge/checkin)
If there are any pending changes then undo all pending changes to all the projects in that solution and any changes to the solution itself
Go to File -> Source Control -> Advanced -> Change Source Control
Select the problem projects and click "Unbind"
Click OK and close the window (THIS IS IMPORTANT - if you don't click OK VS doesn't update the solution properly)
Go to File -> Source Control -> Advanced -> Change Source Control
Select all the projects you unbound in #5 and click "Bind"
Click OK and close the window
Check in your Solution & Project changes
Close the solution and open it back up and everything should be fine now
Also try opening the .sln file from Source Control Explorer, I think that may have been what solved the issue for me.