There is a large ASP.NET web project, made up of many tens of thousands of files developed over the years.
The effective hierarchy looks as:
Site\All.sln
Site\site.csproj
Site\web.config
...
Site\Sub1\sub1.csproj
Site\Sub1\web.config
Site\Sub1\page.aspx
...
Site\Sub1\Sub1a\sub1a.csproj
...
Site\Sub2\sub2.csproj
...
Site\bin <-- all assemblies compiled to here
The back-end code compiles fine and the project runs page.aspx without errors, as when executed IIS understands the nested web.configs (ie. Site\web.config is the root config and Site\Sub1\web.config inherits from the root config).
However, when editing page.aspx (as part of the Sub1 project) in Visual Studio 2022, IntelliSense is reporting errors (ie. 'assembly not referenced') because it does not understand Site\Sub1\web.config is a child web configuration that will inherit from the parent web.config.
There are other issue as well, such as not seeing/understanding the <system.codedom> (root web.config change to enable Roslyn) and/or that Site\bin is where the assemblies will be loaded from (which break aspx editor highlighting when non-SN shared assemblies are added to <assemblies>).
Without moving all the projects into the top-level folder:
- Is it possible to get Visual Studio to apply the web.config as though it was actually running?
- Similarly, is it possible to get Visual Studio to understand 'Sub1/Page.aspx' (not 'Page.aspx') is the relative path when the site is deployed?
A significant reason to not moving all the project files to the root folder, besides a fair bit of tedious semi-automated effort, is that it is very hard for VS to handle a 'show all files' in such a scenario. It is also painful (slow and management issue) to negate paths in SDK-style projects.