@mavasani

Thanks @tmat - I think you need to make few more manual updates to projitems for my PR merged after your merge yesterday: https://github.com/dotnet/roslyn/pull/42655/files?file-filters%5B%5D=.cs added 4 more files to different shared projects, you will need to manually edit the projitems to add entries for these files.

@tmat I would be fine with keeping the current form, and letting this get worked out from the project system side. The very fact that we're using shared projects means we've already accepted suboptimal behavior on well-known code paths.

@sharwell - I have extremely strongly concerns on the current unsupported form. Shared projects does have other bugs but majority of VS tooling works fine prior to the globbing change - I have had no issues in working in shared projects during the port work at all. Corruption due to globbing makes VS completely usunable to the extend that I would consider it as blocking for the porting work for moving analyzers/fixer/tests to shared project.

@mavasani Would it work for you to perform file moves/deletes in file explorer instead of solution explorer?

Let me list out of the pros and cons of the globbing approach here and we all can decide if that is workable:

1. PROS:
   1. Cleaner project files
   2. Lesser merge conflicts in projitems files
2. CONS:
   1. Moving a file between shared project removes glob entry. The edited shared project fails to build with tons of cascaded errors. Someone with no knowledge about this issue may spend hours to fix it.
   2. Deleting a file accidentally added to shared project causes the same problem.
   3. Adding a file causes an additional entry in projitem files (the issue already reported by @tmat). Any change that is affected by this has to make sure that they manually undo changes to projitem files before submitting a PR.

All of the above cons have the big pain point of requiring complete unload/reload of the solution, especially after moves/deletes which corrupts. It makes anyone working on the solution stop trusting the tooling. I am concerned this might happen very common for even new analyzers/fixers we add to shared layer, because any such work will likely need moving extensions utilities down from shared workspaces extension project to shared compiler extension project (move files between shared project scenario).

Personally, I would rather live with VS tooling doing the right thing and slightly cluttered project files rather then be in a state where we cannot trust VS tooling.

@tmat I am expecting the build to fail for the commit I just pushed. This change validates our projitems remain in a valid state so they can be converted back to globs in the future. Some items in the projects were unintentionally included by the direct revert (which is why commit fb6e69d should fail in CI). Once I validate the failure I'll push another commit to add the expected files back.

+1 for Sam's validation change. I am fine to signoff on this change as the PR will now be green only once all the required files are included in the shared project.

Sounds good. Unfortunately, the CI seems broken atm.