StephenMolloy
commented
1 year ago I was only on the periphery of this project when it was being created... but my recollection is that this choice was made as an isolation/safety measure. Both in-proc and out-of-proc were considered... and iirc there might have been a very, very small performance edge to the in-proc implementation in our simple single-site testing. But not nearly enough of an edge to justify staying in-proc.
At the end of the day, ASP.Net and IIS are multi-tenant. (Even if practical guidance is to use IIS AppPools for isolation.) The potential for two different apps from two different entities to co-exist in the same process means we need to be conscious of the potential for one of those apps to abuse the roslyn system and cause disruption for the other app.
Also, even if there is no intentional abuse of the compiler by another in-proc web app - IIS worker processes and ASP.Net caches are tuned and limited by memory use. Keeping the compiler out-of-process keeps the memory usage of a worker process more stable and predictable - consistent with the previous in-box csc.exe usage - so there wouldn't be any unintended side effects from bringing the compiler in-process.
Finally, the way that the VS design-time build system and ASP.Net compilation system co-exist is a somewhat delicate balance. We actually have to package the Roslyn toolset directly in this package rather than simply bringing it in as a normal nuget dependency. We want to avoid trying to get two different versions of Roslyn to co-exist in the VS design-time process as that is unlikely to be a fruitful endeavor.
If you're using CodeDom and this package in a non-web project in an msbuild environment... all the above sounds pretty silly. But the package was originally designed to bring Roslyn to ASP.Net. So these were all pretty serious considerations.
Hi,
I just curious in one question: Was there any specific reasons to run the compiler out of process through cmd? Of course the regular implementation of CodeDomeProvider works in the same way with previous compiler, but still curious, probably any security concerns?
Why I ask.. because it seems to me like there a lot of overhead to run the compiler in a seperate process each time without any possibility to configure it more granulary using Micrsoft.CodeAnalysis directly and probably reuse some things, instead of do the same stuff again and again (especially about metadata references, symbols and things like that).