The old project format of Visual Studio lists all files which logically belong to that project. The file system also contains a catalog of those files. This is redundant; hence the new SDK format implicitly includes all files under the project directory, and you have to exclude files explicitly if you don’t want them to be logically part of the project.
Redundant storage screams for errors. There can be files on disks that are not included in the project file (csproj). I called them orphaned files in the title. It’s a sign of sloppiness, and it can cause problems when a tool works by enumerating files in the project directory and not using the project file as a source for its operation. E.g., file generators.
Uncovering discrepancies in both ways (project refers to a non-existing file or there is a file that is not included in a project) needs tooling. Fortunately, there is such a tool. Extension download location: Show Missing Files. Source repo.
After you install this Visual Studio Extension, it activates itself when you build your solution. You will see the result of the analysis in the Error List Windows.
What kind of garbage can be found?
If the solution is migrated from TFS to GIT, you will see many .vspscc files. Delete them all.
You will see misspelled files. For example, a programmer created a file named “Cunt.cs” and committed it to source control. Later, he realizes the mistake and wants to name it “Count.cs”. However, instead of renaming the file, he creates a new one with the proper name and copies the content of the old file to the new one. Don’t ask why one does such a thing. He then removes the Cunt.cs from the project, but VS does not delete it from the disk; it removes it from the item list inside the csproj. A new orphan file is created.
Another example: an improperly configured code generator sometimes sprinkles files around, and someone mistakenly commits them to source control. Later a colleague runs the fixed generator but does not clean up the old files.
You might find old versions of JQuery and other Js libraries hanging here and there. If the bundling is not configured correctly, it may pack more than one JQuery versions, which can cause severe problems on the client side.
To make it straight, there are 3 cases:
- The file exists, but csproj does not refer to it
- You might want to add it to the project
- Or you might want to delete it because it is just a remnant, a garbage
- The file does not exist on the disk, but the project file refers to it. You have to remove the reference to the nonexisting file.
Here are the possible actions for each item.
1.1. The tool mentioned above can mass-add the files to the project to which they belong by a context menu in the error windows. This is very useful, for example, when you have a code generator that generates many files to different folders and projects without modifying the project file. It is hard to examine all subfolders and add the new files to the project files manually.
1..2: Mass delete the orphaned files for you. Then it’s up to your source control to find out which files are deleted and remove them from the code repository. The TFS Source Control is incapable of such a heroic task; you need external tools to let it know what changed in your source-controlled files (if you don’t want to hunt those files manually). TFF SC is ridiculous and pitiful at the same time. Fortunately, GIT works as expected.
2. It can change the project files to remove the bogus reference to the non-existing files.
You might ask, who cares about the discrepancies between the file system and the project files? They don’t affect the build. Generally, they are harmless. However, these small sloppy things always remind me of the “Broken Window Theory” from the Pragmatic Programmers book (what I read a decade ago).
“neglect accelerates the rot faster than any other factor."
You can read about this principle here. Then don't leave broken windows in your code!