The CodeDom provider type "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider" could not be located

It's a WebApi project using VS2015.

Step to reproduce:

1. Create an empty WebApi project
2. Change Build output path from "bin\" to "bin\Debug\"
3. Run

Everything is working perfectly until I changed Build Output path from "bin\" to "bin\Debug\" In fact, any Output path other than "bin\" won't work.

One little additional thing is that, having another output path to anywhere would work as long as I left a build in "bin\".

Please help providing solution to solve this. I guess that'll cost problem on actual deployment.

Solution 1:

If your project has Roslyn references and you are deploying it on an IIS server, you might get unwanted errors on the website as many hosting providers still have not upgraded their servers and hence do not support Roslyn.

To resolve this issue, you will need to remove the Roslyn compiler from the project template. Removing Roslyn shouldn't affect your code's functionality. It worked fine for me and some other projects (C# 4.5.2) on which I worked.

Do the following steps:

1. Remove from following Nuget Packages using command line shown below (or you can use GUI of Nuget Package manager by Right Clicking on Root Project Solution and removing them).

   PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
   PM> Uninstall-package Microsoft.Net.Compilers
   

2. Remove the following code from your Web.Config file and restart IIS. (Use this method only if step 1 doesn't solve your problem.)

   <system.codedom>
   <compilers>
     <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701" />
     <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" />
   </compilers>
   

Solution 2:

Be careful of following this answer's advice. While it solves the problem at hand, it might cause different problems at a later date.

I got the same problem. Apparently the .NET compiler was not loaded to the GAC. What I did to solve it was:

First, in the package manager console type:

PM> Install-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Now, for some reason the nice gentlemen in Microsoft have decided not to install it to the GAC for us. You can do it manually by opening the Developer Command Prompt and typing:

gacutil -i "C:\*PATH TO YOUR APP CODE*\bin\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll"

Conclusion

Microsoft try to encourage everyone to do everything with nugets which could be fine without the occasional bugs you run into with the nuget system. Try to use the same project on different solutions, accidentally (or not) update one of the many nugets it uses on one of them, and if you are unlucky you'll see what I mean when you try to build the other solution. On the other hand, putting files in the GAC can also cause future problems since people tend to forget what they put there and then when setting up new environments they forget to include these files. Another possible solution is to put the files in a central folder for 3rd party dlls (even though it's strange to call the compiler 3rd party), which creates problems of broken references when setting up new environments. If you decide to install the dll to the GAC, use caution and remember that you did so. If you don't, download the nuget for each project again and bear all the annoying bugs being caused by it (at least used to happen when I finally got sick of it and just placed the files in the GAC). Both approaches might give you headaches and create problems, it's just a question of which problems you prefer to deal with. Microsoft recommends to use the nuget system, and generally, it's better to listen to them than to an unknown programmer in SO, unless you are completely sick of the nuget system and used to deal with the GAC long enough for it to be a better alternative for you.