Not yet but I plan to look into it when I get back from my ONE WEEK HOLIDAY...sorry, was I shouting?
Presently I manually edit
csproj files like thus...
<Compile Include="..\Path\To\ParentFolder\*.*"
Exclude="..\Path\To\ParentFolder\NotThisOne.cs;..\Path\To\ParentFolder\NotThisOneEither.cs">
<Link>ParentFolder\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
<!-- Visual Studio loves to refactor these things so I always add it as a comment too so I can restore it.
Source Code repo check-ins are an easy way to spot this when it happens.
<Compile Include="..\Path\To\ParentFolder\*.*"
Exclude="..\Path\To\ParentFolder\NotThisOne.cs;..\Path\To\ParentFolder\NotThisOneEither.cs">
<Link>ParentFolder\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
-->
<!-- This sort of abomination is also possible, if not advisable -->
<Compile Include="..\zSourceCode\**\*.*" Exclude="..\zSourceCode\Properties\AssemblyInfo.cs;..\zSourceCode\bin\**\*.*;..\zSourceCode\obj\**\*.*;..\zSourceCode\**\*.csproj;..\zSourceCode\**\*.user;..\zSourceCode\**\*.vstemplate;..\zSourceCode\readme.txt;..\zSourceCode\**\*.lsp;..\zSourceCode\**\*.scr;..\zSourceCode\**\*.ico;..\zSourceCode\**\*.txt">
<!-- This has an absolute path with a variable previously declared in this or another .csproj file -->
<Compile Include="$CadExtensionClassesRootFolder$\Common\*.*" >
<Link>Common\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
Upsides
- the files show up in the project you're working on as linked files
- portable if the paths are relative within the same source control repo
- works in Visual Studio version everything
Downsides...there are many...
- Adding a file to the wrong project is too easy
- You need to reload the project with the linkage in it to refresh the view.
- Often when you edit a file the Solution Explorer highlights it in a project you weren't expecting
- Hand-editing .csproj files gets boring pretty quickly
- Housekeeping is generally a bit of a nightmare
- Visual Studio loves to obliterate these wildcard expressions and replace them with a specific list of files, I usually add the same XML as a comment so I can re-edit the csproj file (hence the example above)
- Did I mention hand-editing .csproj files gets boring pretty quickly?
For those wondering "Why Bother???" ... shared projects / my hack above is a great way to have one lot of source code to maintain for different projects for...
- Core Console vs AutoCAD
- Different versions of AutoCAD
- RealDwg
- OEM
- BricsCAD, NanoCAD, IntelliCAD, ARES etc projects
- Library code for all your things - that path in the example is relative but it can be an absolute path and can contain Environment Variables so if you are consistent about where you put your code on different computers than this can work well. I use %Codez% & %Dropbox% Environment variable everywhere.
... if you're copy-pasting source code around projects to build all these different things then you have a bigger housekeeping headache than just a few
csproj files. Tip: Conditional compilation symbols and
#if ... #endif are your friends in the monolith source code repo. As bothersome as the housekeeping on this has been, I have found this
much easier to maintain than duplicate source code.
...the more I think about this the more I think this would work better as an imported project that has no project references, build configs etc. but housekeeping would still be tricky and it would still involve manual editing of .csproj files.