When working with Visual Studio 2015, developers often encounter the .vs folder, leading many to question whether this folder should be included in source control. Let's delve into the purpose of this folder, its contents, and whether it should be checked into your version control system (VCS).

Understanding the .vs Folder

The .vs folder is an artifact of Visual Studio 2015 created at the root of your solution directory. It contains user-specific settings and state information relevant to your local development environment.

Contents of the .vs Folder

1. vs Folder: This subfolder includes a .suo (Solution User Options) file, which stores user-specific settings like the IDE state, UI configurations, breakpoints, last opened files, etc.
2. ApplicationHost.config: If you're working with web projects, this file may appear within the .vs folder, serving as the configuration for IIS Express. It contains local server settings, such as bindings and site configurations.
3. .sln.DotSettings.user: When using ReSharper or other plugins, this file might store user-specific configuration settings which do not affect how the project is built but may impact code styling or inspection settings.

Reasons For and Against Adding .vs to Source Control

Pros of Including .vs

• Shared IIS Express Configurations: In rare scenarios, if consistent IIS Express settings across a team are necessary, sharing the ApplicationHost.config may be advantageous. However, managing such shared settings in source control is not generally recommended.

Cons of Including .vs

• User-Specific Settings: The .vs folder typically contains IDE settings specific to an individual developer's environment. Incorporating these into source control can create conflicts and unnecessary clutter. Each developer has personal preferences, and forcing one setup can reduce efficiency.
• Non-Portable Configurations: Files in .vs are not portable. Path-specific settings in ApplicationHost.config could break when projects get moved or cloned by other developers.
• Increased Repository Noise: Including ephemeral data increases repository size and noise, making it harder to identify pertinent changes during code reviews or during the merging process.

Best Practices for Source Control with Visual Studio

Given the contents and purpose of the .vs folder, the best practice is to exclude it from source control. Here is a recommended approach:

• Use .gitignore/.tfignore: Add .vs/ to your .gitignore or .tfignore file. This ensures that the folder and its contents are ignored during VCS operations.
• Shared Configuration Management: For settings or configurations that must be synchronized across a team, consider using project-level configurations or environment setup scripts outside the .vs folder.
• Build and Deployment Scripts: To handle necessary setup, use scripts for configuration that can be safely versioned without impacting user-specific IDE settings.

Key Points Summary

Below is a summary table outlining the primary considerations regarding the .vs folder:

Conclusion

The .vs folder should not be added to version control. It is designed to encapsulate individual developer settings, which vary from user to user. Excluding this folder helps maintain clean and efficient repositories. Developers should instead focus on using project-level configuration mechanisms to handle any shared settings. The clarity and cohesion of the team’s source control practices benefit from limiting the repository to contain only what's necessary for building and deploying the application.