我有一个 Visual Studio 解决方案。目前，它是一个空解决方案（即没有项目），我已经添加了一些解决方案文件夹。
解决方案文件夹似乎只是“虚拟文件夹”，因为它们并没有真正地在文件系统中创建，而解决方案文件夹中的文件只是坐落在与 .sln 文件相同的文件夹中。
是否有一个设置被忽视了，可以告诉 Visual Studio 将解决方案文件夹视为“真实”文件夹，也就是说，在我将文件移动到这些文件夹中的一个时，它会在文件系统中创建该文件夹并将文件移到其中？
编辑：谢谢。接下来我将为 VS2010 提出建议 :)
有一个解决方法，可以按预期运行。
完成了。现在，解决方案资源管理器将反映文件系统中的任何更改，反之亦然（包括子文件夹）。
我滥用它来做规格、文档、PM 和一些 DevOps 脚本，这些都是在团队内共享的。可以轻松选择要包含在源代码控制中还是不包含，并且（如果正确设置）它不会与构建冲突。
我知道这个功能不是为那种用例而设计的，但除了可能误导人的“项目”图标外，我还没有发现任何缺点。仍然存在传统（虚拟）解决方案文件夹适用于 VS 提供的情况。你怎么看？
.*proj 格式的解决方案类型就好了。 - shannon没有特殊设置。我认为不支持。
您可以在解决方案中的“项目”内创建真实文件夹，但不能在解决方案本身中创建。
。所选答案建议使用实际项目代替解决方案文件夹，但并未真正解释如何做到。我猜我在这里描述的可能是实现这一点的最不尴尬的方式... :-P
常规项目文件的问题是它们最终将由MSBUILD编译。如果您想要一个只包含非可编译文件的项目，那将是一个问题。
但是，不久前，Visual Studio引入了一种新的项目类型：共享项目（.shproj扩展名）。该项目类型默认情况下不会被编译，只有在被另一个项目引用时（且仅当它被引用时）才会被编译。
因此，这里的一个技巧是使用共享项目而不是解决方案文件夹。显然可以添加一个从未被任何其他项目引用的共享项目，这意味着我们可以避免上述问题。
然后，通过在.shproj文件中使用<None Include="**/*" />子句，我们可以使其自动反映任何新文件和/或子文件夹。
因此，基本上是这样做的：
例如，在我的情况下，我创建了一个名为DockerDev.shproj的项目，因此我可以将一些我们仅在开发机器上运行的与Docker相关的脚本分组：
<?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>
这个 .shproj 文件将跟踪解决方案中新的 DockerDev 文件夹中的 任何 文件，包括其子文件夹中的文件。
据我所见，这个解决方案基本上就像 OP 请求的那样工作：它将作为指向文件夹的不可编译引用，并自动反映其中进行的任何更改。
您只需要将新的解决方案文件夹的嵌套级别和名称与实际文件系统文件夹同步，就可以完美运行！
Sara Ford贡献了一种宏来实现此操作。在Visual Studio 2010中，如果您打开宏资源管理器，您将看到一个名为“GenerateSlnFolderOnDirStructure”的宏。这将自动创建解决方案文件夹并添加文件。
Cecilia Wirén - CeciliaSHARP的“将文件夹转换为解决方案文件夹”
消除向解决方案文件夹中添加多个文件的麻烦。只需使用解决方案的上下文菜单，在创建新解决方案文件夹选项的下方，您现在会发现“将文件夹作为解决方案文件夹添加”。这将创建一个与所选名称相同的解决方案文件夹，并将该文件夹内部的项目添加到解决方案文件夹中。这不会移动磁盘上的文件。
对于Visual Studio 2019中的C#，我使用了这种方法（看起来类似于这个答案，但至少在C#解决方案中不起作用）
切换视图
文件夹视图
...只需打开一个具有多个项目的解决方案，并尝试通过文件夹视图将项目移动到其他实际文件夹中。问题是VS不会更新解决方案文件中项目的路径
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "src", "src", "{9D8C3BB1-AEDB-4757-8559-995D12A4E6D0}"