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
Currently the feature only works when VS is running Roslyn OOP.
This is to isolate the query execution better and avoid crashing the entire VS if something goes wrong or consume VS process resources.
In addition we are taking advantage of .NET features not available on Desktop, such as managing assembly loading via AssemblyLoadContext and unloading of the generated assembly. We wouldn't be able to unload the assembly when running on Desktop (the assembly itself would leak and we might want to clear all generated static variables to avoid accidentally leaking Roslyn solution snapshot).
With this in mind and some restrictions we could potentially support the feature running in-proc.
The text was updated successfully, but these errors were encountered:
as this is running arbitrary code, including code taht can stack-overflow, my preference would be that we never run things in proc. An isolated process seems like an ideal way to keep things safe.
Currently the feature only works when VS is running Roslyn OOP.
This is to isolate the query execution better and avoid crashing the entire VS if something goes wrong or consume VS process resources.
In addition we are taking advantage of .NET features not available on Desktop, such as managing assembly loading via
AssemblyLoadContext
and unloading of the generated assembly. We wouldn't be able to unload the assembly when running on Desktop (the assembly itself would leak and we might want to clear all generated static variables to avoid accidentally leaking Roslyn solution snapshot).With this in mind and some restrictions we could potentially support the feature running in-proc.
The text was updated successfully, but these errors were encountered: