Open RikkiGibson opened 6 months ago
@jaredpar @chsienki do you have a sense of when we will be able to make this change? Did we already adjust the way the EA DLL ships so that it will actually always be in sync with the compiler?
We removed the Razor Compiler EA DLL entirely because it's extremely hard to get right. Requires every singcle host of the compiler (VS, VS Code, Workspaces, any tool that hosts the compiler, etc ...) to also correctly deploy the DLL.
In the future we'd prefer putting experimental APIs in the main DLLs or using reflection to experiment.
Got it, it sounds like nothing is blocking us from making the change proposed in this issue right now.
If we want to keep supporting scenarios where new Roslyn-based tools can analyze older Razor projects (e.g., via MSBuildWorkspace, see https://github.com/dotnet/roslyn/issues/72015), we should keep these APIs around, if only as stubs, no matter if the EA DLL is currently shipped or not.
In https://github.com/dotnet/roslyn/pull/71879#issuecomment-1945599764 we found that removing the fields
TrackIncrementalSteps
andDisabledOutputs
and replacing with properties was causing a breaking change in Razor EA when an older Razor compiler is in use.I think that eventually, all Razor compilers which use this EA DLL will fall out of support. Until then we have to keep these around as fields.
This issue is referenced in source