Visual Studio Solutions Folder as real Folders

No special setting. I don't think it's supported.

You can create real folders in a "project" within the solution, but not in the solution itself.

In Visual Studio 2017, click on the "Solutions and Folders" icon in the Solution Explorer window. This button toggles from the virtual "solution" view into a "source view" that matches the layout of folders and files on the file system. When you add a new folder, the folder is physically created in the expected location. .

There is a workaround, that actually behaves as expected.

1. Add a New or Existing Web Site to the Solution. (I usually create a new one.)
2. Just make sure it's created inside your solution folder. (I sometimes even create a "link" to an external folder, e.g. 'Docs' or 'Marketing' on a network share. In that case it's ignored by Git of course.)
3. Make sure to go to the "Project" settings or Configuration Manager to exclude this "Web Site" from Build and Deploy!

Done. Now Solution Explorer will reflect any change in the file system and vice versa (including subfolders).

I (miss)use it for specs, docs, PM and some DevOps scripts that are shared within the team. It's easy to choose, what to include in source control or not, and (if set up correctly) it doesn't conflict with build.

I know the feature is not intended for that use case, but except for the maybe misleading "Project" icon I didn't find any shortages to that hack yet. And there still are use cases where the classical (virtual) Solution Folders that VS provides, fit in the picture. What do you think?

The chosen answer suggests it would be possible to use actual projects instead of solution folders, but does not really explain how. I guess what I'm describing here is possibly the least awkward way of achieving that... :-P

The problem with regular project files is that they eventually will be compiled by MSBUILD. And if you want have a project which only contains non-compilable files, that will be an issue.

But some time ago Visual Studio introduced a new project type: Shared Project (.shproj extension). This project type does not get compiled by default, but only when (and only if) it is referenced by another project.

So one part of the trick here is to use shared projects instead of solution folders. It's obviously possible to add a shared project that is never referenced by any other project, meaning we can avoid the issue presented above.

Then, by using <None Include="**/*" /> clause in the .shproj file, we can make it automatically reflect any new files and/or subfolders.

So basically do this:

• Create a new folder in your solution.
• Add a new .shproj file at the root of this new folder.
• Reference the new .shproj in your solution.

For instance, in my case, I've created a DockerDev.shproj, so I can group some docker-related scripts that we run only in our development machines:

<?xml version="1.0" encoding="utf-8"?>
<!-- DockerDev/DockerDev.shproj -->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <None Include="**/*" />
  </ItemGroup>
</Project>

This .shproj file will keep track of any file, in any subfolder of this new DockerDev folder in my solution.

As far as I could see, this solution works pretty much like what the OP requested: it will work as a non-compilable reference to a folder, and it will automatically reflect any changes made to it.