Problems publishing a website on smarterasp.net with csc.exe file included?

Question

I am using Microsoft Visual Studio 2015, I built a simple website with a C# contact form. When I compile and run on localhost it works perfectly fine. However, when I try to

Answer 1

I had this issue on Smarter ASP. On the browser file manager in the control panel, navigate to 'Roslyn' folder in bin and set .net permission to read/write. It worked then.

Answer 2

Just set rw access for /bin folder in Smarterasp.net File Manager as shown below, restart your app

Answer 3

Just remove the codedom section from the Web.config, this solves the problem.

Answer 4

The above solutions did not work for me and are not correct, since roslyn is not optional these days.

What worked was ensuring that the pool account had read & execute permissions on the root folder of the web application. You can find the account to grant this permission to by finding the Pool name your web app uses, then Application Pool -> pool name -> Advanced Settings -> Identity.

My VPS host uses non-standard directories for hosting as follows:

c:\home\web.app.name\wwwroot

The web.app.name folder needed the permission.

Answer 5

After hours of researching i came up with the solution.

Since the .NET 4.5 version, Roslyn compilation is the default way of compiling. This means if you create any web application either Web Forms or MVC using .NET 4.5 you get this Roslyn csc.exe compilation pre-installed in your project.

Basically what i needed was to compile and deploy my project without Roslyn or any .exe files on it.

So here is the Solution that worked for me. You can deploy without Roslyn with no change in code:

1. Open NuGet Package Manager window
2. uninstall Microsoft.CodeDom.Providers.DotNetCompilerPlatform package and rebuild & republish. (This uninstallation also removes CodeDom configuration from web.config file.)

This will solve your purpose. Basically this will not generate any csc.exe, vbc.exe files inside bin folder.

I hope it works for you too!

Answer 6

Updating the nuget package Microsoft.CodeDom.Providers.DotNetCompilerPlatform to the latest version (at that time) 2.0.1 resolved this issue for me without having to grant permissions to the folder or remove the compiler.