Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

People also ask

What is Microsoft CodeDOM?

The CodeDOM provides types that represent many common types of source code elements. You can design a program that builds a source code model using CodeDOM elements to assemble an object graph. This object graph can be rendered as source code using a CodeDOM code generator for a supported programming language.

What is DotNetCompilerPlatform?

DotNetCompilerPlatform 1.0. 2 package is released on NuGet. It enables ASP.NET to support the new language features and improves the compilation performance. To install this NuGet package, open NuGet Package Manager in visual studio, search Microsoft.


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>
    


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.


Just add the next nuget package to your project - Microsoft.CodeDom.Providers.DotNetCompilerPlatform.

Had the same problem.


I have the same problem that my app worked in Vs2013 but getting the error after updating to Vs2015.

  1. In Vs2015, right click project's References folder, to open NuGet Package Manager
  2. Under Browse tab, search for "DotNetCompilerPlatform" and install "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" lib

I know it's an old thread, but I'd like to point the possible version issue of DotNetCompilerPlatform.dll, f. ex. after an update. Please check, if the new generated Web.config file is different as your released web.config, in particular the system.codedom part. In my case it was the version change from 1.0.7 to 1.0.8. The new dll had been already copied to the server, but I didn't change the old web.config (with some server special settings):

<pre>
  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /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.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" />
    </compilers>
  </system.codedom>
</pre>

After I update the two lines, the error disappeared.


Another possible solution:

➜ Restart your Visual Studio Instance with Administrator Rights

enter image description here


According to your repro steps, I assumed that changing the output path in the application's property was your only change after you created the application. The only thing this change does is that it tells Visual Studio to put the output assemblies of MSBuild into the new folder. At runtime, however, ASP.Net wouldn't have any idea that it should load assemblies from this new folder instead of the \bin folder.

This answer shows the way to change the build output directory of a WebApi application. To get the exact same error showed in that post, you need to comment out the entire <system.codedom> section in web.config. And then you can follow the instructions to change the output path.

After you get your applicaiton work, you may then uncomment the <system.codedom> section. If you don't use C# 6 new syntax in your application at all you can uninstall the Microsoft.CodeDom.Providers.DotNetCompilerPlatform from you application; otherwise, you may want to add the following command line in your post-build event,

xcopy /Q /Y "$(TargetDir)roslyn\*.*" "$(TargetDir)..\roslyn\"

The new CodeDom provider always looks for the "\roslyn" folder in \bin. The above command works as a workaround and copies the \roslyn folder from your new output folder to \bin.

In my experiments, the publish tool of Visual Studio, however, published the output assemblies to the \bin folder in the deployment location regardless my output path setting. I guess your application should still work on actual deployment.