Feature Request: Add Globbing Pattern Support for Files in .slnx

[kasperk81]

Feature Request: Add Globbing Pattern Support for Files in .slnx

I'd like to suggest adding support for globbing patterns in .slnx files, similar to how it's done in .csproj using the Microsoft.Build.Globbing package. This would make managing large solutions simpler, especially when adding multiple files.

For example:

<File Path="test\**\*.cs" />

This would help dynamically include files without needing to list each one individually, streamlining file management.

For more context, please refer to the Microsoft documentation on file globbing.

[alrz]

Following sdk-style project format I think this should be the default for csproj files because the solution structure is usually in sync with file system, including any subfolders.

<Solution Sdk="...">
  <!-- Includes every csproj, directory props, targets by default -->
  <Project Remove="Project.csproj"/>
  <Folder Path="Solution Items"> <!-- Could be implicit as well? Why would you not want to include this? -->
     <!-- Includes all files in the root -->
     <File Path="*.*" /> 
  </Folder>
</Solution>

Right now there must be an additional definition per each directory.

[jnm2]

This would solve a longstanding pain point. Most times when I add a new file to a solution folder, I have to create it separately and then add as an existing file as a separate step. It's very manual and it's easy to forget to keep it in sync. It would be incredibly nice if the solution folder would dynamically update.

[pebezo]

This is the missing feature! The current solution behavior is to create a "virtual view" over how files and projects are actually laid out on disk. Especially as a solution grows, keeping track of the reality on disk becomes harder and more disjointed. Yes, we have the "file system" view, but that's a hack at best since we lose a number of benefits from the solution view.

Having something like this would allow us to poke holes (portals?) into this virtual view. I find that the root folder is usually the most problematic. All the .gitignore, .yml, docker files etc. end up there because other 3rd party tool require them to be there, but VS (and other .NET IDEs) make us leave the IDE and/or fight against us being able to do this.

[304NotModified]

From the Visual Studio Blog:

Will file globbing be supported?

The current solution design lists all projects and their locations directly in the solution file. This approach allows Visual Studio to begin loading projects almost immediately.

Supporting globbing, would require scanning the file system and evaluating potentially complex patterns to identify matching projects. Especially for larger repositories, this additional step can significantly slow down the loading process which is why globbing is not currently supported.

If this is a performance issue than:

• I'm also OK if the globbing also works on load of the solution and with a manual button
• We only need globbing for the solution files, not for the projects, e.g.

ProjectSection(SolutionItems) = preProject
 azure-pipelines.yml = azure-pipelines.yml
 readme.md = readme.md

[kasperk81]

As everyone familiar with globbing knows, its performance depends on the permissiveness of your glob pattern. So, any system that supports globbing is aware of this, and there's nothing to be worried about. VS will just show the loading bar longer for poorly authored patterns.

MSBuild has supported globbing for several years (since 2017, perhaps?), and these concerns have proven to be non-issues in the real world. It all works out in VS with decent usability.

[robertmclaws]

Yes, please add this feature! Having to have a node per file in a complex path structure is... cumbersome.

[lukasvosyka]

I think too that this would be a helpful feature in some scenarios such as mono repos. Having many projects and having the need to also maintain the .slnx file is cumbersome when you could just have set up rules. Please do not disallow something useful, just because you think it might result in slow loading times. Let the developers/team decide what the right thing is for them.