You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #71879 (comment) we found that removing the fields TrackIncrementalSteps and DisabledOutputs 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
The text was updated successfully, but these errors were encountered:
@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.
If we want to keep supporting scenarios where new Roslyn-based tools can analyze older Razor projects (e.g., via MSBuildWorkspace, see #72015), we should keep these APIs around, if only as stubs, no matter if the EA DLL is currently shipped or not.
In #71879 (comment) 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
The text was updated successfully, but these errors were encountered: