When I right-click on my solution, in solution explorer, and choose Get Latest, Visual Studio gets the latest, but also checks out the solution.
Replacing
C:\DevTfs2010\Apps\Messaging\Subscribers\AutoTrackerProcessor\Main\AutoTrackerProcessor\SolutionItems\SolutionInfo.cs
AutoTrackerProcessor.vssscc, AutoTrackerProcessor.sln have been
automatically checked out for editing.
Not only does it check out the solution, but it removes the SolutionInfo.cs file from the solution file. Here is the compare of the solution file:
Server:
Local:
Why would it do this?
Note: Our build process alters the SolutionInfo.cs file, but only that file. It doesn't alter the solution to remove SolutionInfo.cs.
Related
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 checked the solution file and the project file, and can not find anything related to this setting. When people get latest version from TFS source control, they always see the 'loaded' status, which is not really what I want.
This information is stored in the solution user options file (.suo) which you can find in the same directory as the solution file. As the name implies this is user specific information which means sharing this across the team will be difficult because then everyone will need to live with the same options and store files in the exact location because the .suo file contains full paths.
For anyone else coming here with Visual Studio 2019, the unloading of projects is no longer saved in the SUO (at least in my experience). To save your unloaded project settings, you want to create a solution filter file (.slnf) which is the same as your solution file (.sln) except that it stores which projects you want loaded or not when opening the solution. Once created, you will double-click the .snlf file instead of the .sln file in order to load your filtered projects.
To create the solution filter file you can follow the instructions at this link or follow the summary below:
Open your solution (.sln)
Unload the projects that you want filtered out
Right-click on the solution from within the Solution Explorer
Choose Save As Solution Filter
Choose a location to save the file (I saved it right next my .sln file)
This will add the .slnf to your recently opened solutions list so you can either open from there going forward or navigate to the .slnf file and double-click it.
If you still want to see your unloaded projects after opening the .slnf, highlight the solution from within the Solution Explorer and click the Show All Files icon.
Base on this if you want to share your load/unload setting via source control you can use solution filter file which is .slnf extension.
So when you open the .slnf file instead of .sln file you will see the filtered project are loaded.
On MacOS with Visual Studio 2022 for Mac (i.e. v17.0 Preview, "Visual Studio Community 2022 for Mac Preview") I do not see either .sln nor .slnf files.
I observe that unloaded projects are saved in folder /.vs/[SolutionName]/xs/UserPrefs.xml. And when I close Visual Studio 2022 for Mac, I see that UserPrefs.xml is saved.
UserPrefs.xml Snippet:
<DisabledProjects>
<String>...</String>
</DisabledProjects>
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.
I can open my project by double clicking on the .csproj file. It opens fine and it doesn’t generate a .sln. If I copy the same project to a virtual machine and do the same it opens but creates a .sln file.
I really don’t need a solution I would prefer to only work on a single project.
Am I missing something here?
Visual Studio always creates a solution. If it cannot find one in the same folder as the .csproj file then it will create one itself, based on what it can reverse-engineer from the project file content.
The solution is hidden by default if the solution only contains one project. Fixing this is recommended: Tools + Options, Projects and Solutions, General, "Always show solution" checkbox.
There is always a solution, even if you don't see it. There's a setting that determines whether the solution is visible when there is only one project.
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?)