I'm running VS Enterprise 2015. This infernal thing keeps wanting to add my solution's .vssscc file to version control. My .tfignore has this line:
*.vssscc
The other items in .tfignore are working fine, but for some reason this one is not. There are no other .tfignore files in the directory tree. Surely I'm overlooking something, but I'm pulling what's left of my hair out trying to figure out what. Any suggestions?
*.vssscc stands for Visual Studio Solution Source Control File
When a solution is added to source control, a corresponding .vssscc file is created. The text file contains connection information and an exclusion file list, similar to the project hint file. This file is temporary and exists only in the source control database.
As a rule of thumb, we'd recommend letting Visual Studio handle those files. It'll add to source control the files it needs and leave out those not needed.
.vssscc files also manage the solution bindings, so better to have them controlled (by VS) .
Also, visual studio can have problems with the source control bindings if the files it needs are not under source control.
Related
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).
I searched already on stackoverflow and on the internet but I couldn't find a similar specific question.
When i have to rename a already checked-in (tfs) project in my visual studio (2010-2013) solution, I always use a procedure similar to this one here in the accepted question:
stackoverflow.com/questions/2043618/proper-way-to-rename-solution-and-directories-in-visual-studio
Here is the important snippet from there (thanks to author):
Close Visual Studio.
Create a backup of your .sln file (you can always roll back).
Imagine you want to rename directory "Project1" to "Project2".
If not using source control, rename the folder from "Project1" to "Project2" using Windows Explorer.
If using source control, rename the folder from "Project1" to "Project2" using the functions supplied by source control. This
preserves the history of the file. For example, with TortoiseSVN,
right click on the file, select TortoiseSVN .. Rename.
In the .sln file, edit all instances of "Project1" to be "Project2".
Restart Visual Studio, and everything will work as before, but with the project in a different directory.
..and there i always do step 6:
Step 6.: In the .sln file, edit all instances of "Project1" to be "Project2".
By observing the .sln file i could see that until step 6 (so in my case of using the tfs i did steps 1,2,3 and 5) there are still occurrences of the old project name in the .sln file:
Project("{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}") = "Project2",
"Project1\Project2.csproj", "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"
and:
SccProjectUniqueName92 = Project1\Project2.csproj
SccProjectName92 = Project1
SccLocalPath92 = Project1
Until now i had no problems with that approach. But as i could see a colleague of me is skipping step 6 and there are still occurrences of the old project name in the .sln file.
Now i wonder if step 6 is really needed/required?
I am keeping using step 6 just for more cleanness! But whats your opinion on this?
Could the old project name occurrences in the .sln file (if skipping step 6) even some time lead to functional problems with tfs/vs etc.?
Or is it only for the purpose of a cleaner/clearer code better to do carry out step 6?
If you are renaming a project within a solution, that is under source control, really all you need to do is to rename the project in Visual Studio and then submit the changes to the project file and the solution file, back into source control.
Visual Studio and TFS should handle all of the changes for you, VS will rename the project and update the references in the SLN file.
TFS will handle the rename and will maintain the history line.
The only time it should get complicated is if you are moving projects and solutions within source control, when you are carrying out this sort of task then the list above is a fair description of what needs to be done, but after step 4 i would just open the solution remove the project that can no longer be found and add in the newly renamed project, this would then automatically handle the sln file changes. now obviously this would orphan your history on the project if it was under source control, but you would make the project name change through TFS before reopening the solution.
if you want to manually change the sln file then a find and replace operation is the simplest way to update the file.
Coming Back to your question.
You really should ensure the sln file is correct as this tells VS where to download the files from and what projects actually make up the solution, by not updating the sln file correctly you, or other users of TFS may not get the correct files downloaded and you may have issues opening your solution.
An example of fall out from not having these files in line can be found in this question Why missing <SccProjectName> in project file cause "The project file is not bound to source control"
I'm using Bazaar and Visual Studio 2010 in a C# project. I have prepared an ignore list but still I think all the files in Solution Output directory could be ignored.
I search a lot but nobody had mentioned it. So I'm going to know if I can ignore this directory because output files are changing regularly and seems are not important for repository copy.
What do you suggest about this issue ?
In general, any file that is automatically generated by compiler or build tools should NOT be committed into source control. This includes object files, executables, generated resource files, symbols, etc. Committing those files does not serve any useful purpose. Also, sometimes there are configuration files which look like can be committed, but really should not if they only contain local user specific info - for Visual Studio there are *.user files.
By that logic, solution output folder should be always put into ignore list.
In Visual Studio, if I try to copy a file from one project to another (by using Copy and Paste or by dragging the file to the new project while holding the Ctrl key) it creates a reference to the source file in the original location. Is there a way to create a physical copy of the source file and place that in the target project source direction without having to resort to using Windows Explorer to copy the file manually?
It's not pretty, but when I want to do what you're suggesting, I double-click on the file in Visual Studio, which opens it. Then I do a File->Save As, choose the right directory and save it. All from within Visual Studio. This is usually followed by adding the new file to the other project.
Was just doing this and realized I should mention a side-effect. Depending on your source control (in my case, TFS 2010), doing this from within Visual Studio may modify the location of the file in the project. For me, this means making sure that neither the file nor its project have any pending changes, doing the save as, then doing an undo of the change this causes in TFS 2010 (project change, file add and delete).
From http://msdn.microsoft.com/en-us/library/0fb6xxhb.aspx:
If you are working with solution items, Visual C++ projects, or other similar projects, you are always working with links in Solution Explorer. If you are working with Visual Basic projects, Visual C# projects, and other projects, you might be working with links or files.
Essentially, the answer to my question is 'No'. In most cases, I must use Windows Explorer.
Got a bit of a weird problem. I'm checking a solution out of TFS source control, and not making any changes to it; just opening it using the SLN file. If I then close Visual Studio (or do a Save All), Visual Studio prompts me to save the SLN file. Even if I do (by overwriting it, it's a read-only file), it continues to do this every time I open and close the solution, as if I'd added a project or something. Why would Visual Studio do this? What's causing it to think the solution has changed and needs saving?
OK, problem solved. As we're using TFS for source control, you're meant to check in the SLN file's corresponding .vssscc file. As we'd checked in the .vspscc for the various projects the SLN file pointed to but not the SLN's .vssscc file, Visual studio didn't consider the solution to be bound. :-)
Fixed it by going to File | Source Control | Change Source Control, then binding the SLN file to the solution's root dir on the TFS server. This created the solution's .vssscc file, which we've checked into source control. Subsequent checkouts now don't cause the problem.
I would start by letting it save the solution and then doing a visual diff of the version that it saved vs the one held in source control to see what the problem is. It could just be white space formatting. Also, are you the only person suffering this (if others are using the same solution?)