What / why is Roslyn "needed" in /bin folder of Asp.Net

There are a bunch of related questions on this, though most of the answers define Roslyn and/or provide a "fix" to some issue (exe, with hosting providers, etc.)

What I can't seem to track down is the "why" and "what for" (perhaps only in the context of ASP.Net MVC/Web API) in /bin/roslyn.

I ran in to similar issues (hosting - .exe restrictions, support for 4.6, etc.) and my "fix" was to "just deploy to Azure" (of course everything works without a hitch). But really, this doesn't answer:

• why are they needed?
• does this mean that the they are used for runtime compilation (my brain points to this, but that is a complete guess/my perhaps wrong grok), as this SO post shows - unless corrected, this is "it" (more below).
• it seems "removing the package" is a "fix" (based on some past answers), but if so, it (re)begs the question

I think understanding this will help - e.g. I can't be the only one who will have an eyebrow raised seeing an .exe "needed"....

---

Update

Goes to show that "hidden gems" exist :) I've read this over and over...after all it's been there for some time now - but not the comments thread - the original referenced link, circa 2014, has been redesigned by Microsoft and the comments are no longer displayed...luckily the relevant parts are below.

BIG mistake - it was staring at me all this time (or at least since this exchange):

> Dmitry Dzygin 2 Jun 2015 12:53 AM > > I have tried the latest version of the NuGet package, but there's seem to be a difference in the way the compiler is loaded/executed. > > In the v0.2.0.0 the Roslyn compiler would be loaded into memory, improving greatly performance for not pre-compiled websites with > multiple .asx/*.cshtml files. The new version, however, features a > new /bin/roslyn/csc.exe file, which is executed once per file, > completely removing the mentioned above optimization feature.....

Gold:

> XMao 2 Jun 2015 1:22 PM > > @Dmitry The job of the csc.exe in /bin/Roslyn is to invoke the VBCSCompiler.exe, which sits in the same folder. VBCSCompiler.exe > is the process that does the actual compilation work. If the > VBCSCompiler is already running csc.exe will reuse it and thus we will > still gain the mentioned performance improvement.

Hth...

---

Update: 10/2017

Seems this is relevant after all this time so a further update.

The answer below by @Donny V is an option. By fully compiling your application, including all Views (.cshtml/.vbhtml), you wouldn't need that exe in your application.

This is true even if Visual Studio (to this day, VS 2017, confusingly) will still create the /bin/roslyn and it's contents in the Publish process, even if "full compile" is set.

You can test this by excluding the /bin/roslyn folder and it's contents when pushing your application to your hosting provider.

Caveat:

As mentioned, fully compiling your application means you'll have to recompile it, even for View level changes.

This is taken from MSDN forum.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/442b100a-2b88-4ac4-b655-0c1345791f15/roslyn-cscexe-web-api-2-on-hosting-server?forum=msbuild

> I have noticed a minor drawback to uninstalling this package: > > https://www.nuget.org/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform > > Some of the new C# 6.0 language features if used in Views (MVC > project) will not compile. Many of my views use the ?. null > checking operator for accessing Model properties. All of these views > now return errors on my Godaddy hosted MVC 5 application. > > This error occurs because Views (by default) are compiled at runtime > using the .NET pipeline (not pre-compiled). > > To resolve this issue, simply uncheck the "Allow precompiled site to > be updatable" option in your publish profile settings. This should > pre-compile your views and allow your C# 6.0 (Latest version of Roslyn > Compiler) to run like a champ.

Just wanted anyone looking at this question to know the ramification of uninstalling it and why its there in the first place

Was running into this issue all the time in Visual Studio 2017 Community Edition where the project could not be rebuilt because the older files in bin/roslyn could not be deleted. Based on the OP's Gold comment, I now keep the Task Manager open (Ctrl+Shift+Esc) and kill the VBCS.exe process. The offending files in bin/roslyn can now be deleted.

Another feature of it is that it does not require build servers to actually have compiler dependencies. You send the compiler you want to use WITH the code to the build server and it just uses exactly what you told it to.

This release of Visual Studio contains a new version of C# & VB.net compilers code named “Roslyn”.

Roslyn is a complete rewrite of the C# and VB.net compilers with each written in their respective language for example the C# compiler is written in C# rather than C++. Roslyn is open source (Roslyn on GitHub) so you could even theoretically create your own version of C# or VB.net!

What would become Roslyn, was first mentioned way back in 2008 by Anders Hejlsberg at the PDC conference however it wasn’t until 2011 that the first preview was released.

You could refer to the following links to get more detailed information about your problem.

https://gooroo.io/GoorooTHINK/Article/16253/Visual-Studio-2015-and-Roslyn-Compiler/17944#.VmkfwjaheM8

https://visualstudiomagazine.com/articles/2012/03/20/10-questions-10-answers-on-roslyn.aspx

From: https://forums.asp.net/t/2079727.aspx?What+is+the+roslyn+folder+

Two things to note:

1. Removing it will "fix" the problem, but it "fix"es it by falling back to a built-in, old, legacy compiler that is not compatible with later language features.
2. Pre-compiling is not possible in many cases. How would you show information in a model if it's pre-compiled, and then show changes to that data? Any data that you rely on in partial views to refresh would never update.

Another point of interest is to make sure you are tracking the "build" directory in the roslyn's package. If you don't, it won't thrown an error but it will not compile your site when you try to load it. Fully tracked, it just works. We deployed it to other development systems without installing it on those systems first, and this is possible because it's a NuGet package.