I have a Visual Studio Solution. Currently, it is an empty solution (=no projects) and I have added a few solution folders.
Solution Folders only seem to be \"virtua
Create "Solution folder". This will create logical folder, but not physical one. Right click to the solution folder and open a new project dialog. But before you click OK, you have to change a project location to your desired physical folder and VS will create it and place the project inside.
I've wanted this feature a few times myself, but at the end of the day, you really do NOT want the ability to do this. Think of your Solution (file) as as the root of a web application and think of Solution folders as Virtual Directories (literally and functionally). The contents of a web virtual directory could be physically on a different server altogether. Where Visual Studio muddled up the solution folders concept is by allowing you to create new files inside the folder. You should always "Add Existing" when adding content. When you add existing, it creates a link to the source location of the file.
But as for the reason you do not want solution folders to behave like "physical" folders is because your solution layout may not necessarily use the same convention as your source control layout. Solution folders allow you to customize the hierarchy of your projects so that you can group projects and items together any way you like, and then decide you don't like it and change it again without having to go through the nightmare of moving source control items around and irritating the rest of your team.
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. .
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:
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.
Visual studio has no support for this. I made an extension that does something similar for VS2013 though. It maps solution folders to physical folders on your hard drive, though the mapping is one way (from hard drive to solution). That means a solution folder's contents will reflect the hard drive folder's contents, and not the other way.
With that out of the way, the extension may still be useful. It has support for mapping solution folders to physical folders, filtering files and directories based on regex, and remembering mappings in your .sln file. Properties are non-intrusive so developers without the extension can still open the sln and not be affected.
Hosted on visual studio gallery: https://visualstudiogallery.msdn.microsoft.com/69e19ea6-4442-4cb6-b300-044dd21f02bd
Edit: Uploaded to bitbucket. Now open source. MIT license. https://bitbucket.org/LSS_NorthWind/physical-solution-folders
I have a bit of a workaround for this (it's not great, but it works).
It's not great because you will need to manually maintain the file references, but it works for me.