I have a project which has been taken from TFS via GetLatest, I have read only access and thus am able to get the Latest code. Now I don't have checkout access for the project and thus I want this project to be disconnected, and I can modify some files.
I am trying to do it via Visual Studio 2010 --> File --> Source Control --> Change Source Control but there also, its giving error of no access to do that. Project Files are showing the lock icon against them which shows they are connected to TFS in read only mode.
While using SVN, I used to take the approach of deleting .SVN folders created (by searching .svn folders and deleting them all). Is there any similar approach applicable in TFS?
I was able to do it via the following:
Remove all files of type "Visual Studio Source Control Project Metadata File"
Edit Solution and Project Files and remove some TFS related stuff:
In Solution File remove the section
GlobalSection(TeamFoundationVersionControl) = preSolution
SccNumberOfProjects =
SccEnterpriseProvider =
SccTeamFoundationServer =
SccProjectUniqueName0 =
SccProjectName0 =
SccAuxPath0 =
SccLocalPath0 =
SccProvider0 =
EndGlobalSection
In Project File, I removed some entries:
<SccProjectName></SccProjectName>
<SccLocalPath></SccLocalPath>
<SccAuxPath></SccAuxPath>
<SccProvider></SccProvider>
Hope it works for other too. Thanks.
I use this tool to unbind: http://github.com/ralbu/UnbindTFS
It has the option to ignore folders which is helpful if you have a git repository
From https://stackoverflow.com/a/359145/127434
"File -> Source Control -> Change Source Control and then unbind and/or disconnect all projects and the solution."
Related
Our projects are showing binding status as Invalid.
The problem started when we reinstalled our windows OS.
Steps which I took :
In the VS 2019, I created a new workspace & mapped the TFS server folder to local existing folder(It was working previously with TFS before windows re-installation).
After saving new workspace it asked me to get the latest version, which I did.
Now under Team Explorer > Pending changes > Excluded changes - it shows me Detected (some number) adds (which is whole solution files & folders).
Under Solution Explorer If I right click on any file or folder of this project it shows me - Add files to Source Control.
Somewhere I read to bind solutions, to which I followed this step:
File > Source Control > Advanced > Change Source Control.
Here on all of the Solution/Project I clicked on Bind - The status shows for all as Invalid.
Please someone help me on this. As, I have multiple solutions & all of them have the same issue. They did had pending changes too.
If rebinding doesn't work, you might try editing the solution files directly.
To completely remove TFS source control binding follow these two steps:
Go to your solution's folder, find and delete all files with *.vssscc and *.vspscc extensions.
Open your solution's .sln file in Notepad, and find & remove the GlobalSection(TeamFoundationVersionControl) section.
Below is a sample section that has references to Scc:
GlobalSection(TeamFoundationVersionControl) = preSolution
SccNumberOfProjects = 1
SccEnterpriseProvider = {4CA58AB2-18FA-4F8D-95D4-32DDF27D184C}
SccTeamFoundationServer = http://yourtfs:8080/tfs/defaultcollection
SccLocalPath0 = .
SccProjectUniqueName1 = WebApplication\\WebApplication.csproj
SccProjectName1 = WebApplication
SccLocalPath1 = WebApplication
EndGlobalSection
Reference Link
From: Remove TFS Connection From Solution
After this, you could try to add whole solutions to source control or Bind the solution file to TFS again
Finally bind the solution file (.sln) to TFS again. Do this in visual
studio by going to the menu`File => Source Control => Change Source
Control
More another ways, you could take a look at the solution in this similar question: Re-establish TFS source control bindings
I usually get this problem with my visual studio TFS.
When I add a new item (*.cs, *.js...), it does not add to the source control automatically. But the *.csproj file does include the file.
I am sure that I did not change any related settings.
I solved it by modifying the local config file LocalItemExclusions.config, because there is *.lib in my solution's name, it will be excluded.
When I deleted this line <Exclusion>*.lib</Exclusion> in the config file,
it worked (or you can change the namestyle to avoid it).
Double check if there are folders and branches called Release in your soucre control and their contents is automatically excluded from TFS (along with Debug and lots of file types). You can override this for particular folders by creating a .tfignore file.
More details about the solution please refer this similar question: Visual Studio 2015 new files not being added to source control automatically
If above is not working, check if you source control binding is correctly. File > Source Control > Advanced > Change Source Control.
If not, bind the solution and project to your source control server (unbind first if it's already bound).
When rebuilding the solution, the .sln file is checked out and following section is removed:
GlobalSection(Performance) = preSolution
HasPerformanceSessions = true
EndGlobalSection
Why is it happening and how can I prevent checking out solution file on rebuild?
Using Visual Studio 2015 Update 1 and TFS 2015
Rebuild the solution will not check out the file in source control by default.
The delete action trigger the check out. Because version of the Solution file not sync each other from source control and local project folder.
So, the real problem is why rebuild the .sln file will remove the GlobalSection(Performance) file.
This seems to be caused by the Visual Studio issue, refer to following links for details:
Section in solution file causes continual merge conflicts in a team environment
Visual Studio Performance Explorer adds user-specific information to the .sln file, which causes issues for teams with multiple developers
When trying to switch my solution from using Ankhsvn to VisualHG (we've just migrated from SVN to Mercurial) I kept getting the following message:
"The active solution or project is controlled by a different source
control plug-in than the one you have selected. If you change the
source control plugin, the active solution or project will be closed.
Do you wish to continue?"
The solution would then close and when I re-opened it it would still be linked to Ankhsvn.
I tried deleting the source folder and grabbing a fresh clone out of Mercurial, but the problem kept coming back.
The solution required opening the .sln file in a text editor and manually removing the following block:
- GlobalSection(SubversionScc) = preSolution
- Svn-Managed = True
- Manager = AnkhSVN - Subversion Support for Visual Studio
- EndGlobalSection
After that I was good to go.
The above solution works but another way to do it without editing the sln is to open the project instead of the solution. Then change the setting at Tools->Options->Source Control->Plug-in Selection and change plug-in.
Make sure you save all - this should save the new Source control to the solution.
My solution is:
open solution normally with vs
disconnect all AnkhSvn project bindings
change source control plugin to VisualHG and save all
I have a dev team that is split in mentality of using visual studio source control bindings. Half would like the integration and half would not. Is there a way to add a solution only binding setup so each team could use a different solution based on their preferences?
There is no painless solution to this problem. The reason being that Microsoft made the monumentally bad decision to embed source control information into .NET solution and project files.
Let's say Dick wants to use the SCC plugin and Jane doesn't. Dick adds a project to version control via the plugin and information like this will be written to the solution file:
GlobalSection(SourceCodeControl) = preSolution
SccNumberOfProjects = 2
SccLocalPath0 = .
SccProjectUniqueName1 = someApp\\someApp.csproj
SccLocalPath1 = someApp
EndGlobalSection
and some garbage like this will be added to the project(s) files:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
In addition, some files will be strewn about the project folder tree (MSSCCPRJ.SCC files in the solution and project folders, a *.vssscc in the solution folder, and *.vspscc files in the project folders).
The extra files are not a problem as long as Dick doesn't check them into source control (although the plugin is always going to want to check in those .vssscc and .vspscc files). However, the source control information that gets written to the solution and project files will always be an annoyance for Jane. Whenever she opens the solution, she will be nagged by this message:
and then this one:
Should she choose the option to "Permanently remove source control association bindings", the source control information will be removed from the solution and project files and she will be happy again. However, Dick's SCC plugin won't work anymore and he'll probably rebind the projects to source control and an office riot will ensue.
To sum it up, you can share .NET project between those who use the SCC plugin and those who don't, but one or more parties are going to have to endure some annoyances because Microsoft decided to add source control information to .NET project files (such a bad decision, this wasn't a problem in Visual Studio 6).
I'm not absolutely sure if I got you right. I assume that half of your team wants to use the Visual Studio plugin to access Perforce and the other half doesn't.
This is possible. You have to make sure to never check in the MSSCCPRJ.SCC file created by the plugin. This is the local bindings information and will not work on everybody's workstation.
On the other hand side, the *.vssscc files can and should go into Perforce.
Using the plugin has one big advantage, though: The plugin knows which files to check in and which to omit. Especially when adding new projects, it's a common mistake to forget to check in the newly created files when using the Perforce visual client instead of the plugin.
You have to make sure to never check in the MSSCCPRJ.SCC file created
by the plugin.
I removed *.scc files but Visual Studio prevent me use others Source Controls Plugin's except saved into solution and project files.