LehnerBuild

C#

The CodeDom provider type MicrosoftCodeDomProvidersDotNetCompilerPlatformCSharpCodeProvider could not be located

25 September 2026 · 6 min read

The CodeDom provider type MicrosoftCodeDomProvidersDotNetCompilerPlatformCSharpCodeProvider could not be located

Encountering the error message “The CodeDom provider type “Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider” could not be located” can be a significant roadblock for developers working with ASP.NET applications. This cryptic message often appears during compilation or runtime, bringing development workflows to a grinding halt. It signals a fundamental issue with how your application is trying to compile C code, particularly when relying on modern .NET compilation platforms. Understanding the root cause of this specific CodeDom provider error is crucial for efficient troubleshooting and ensuring your projects build and run smoothly. This article will delve deep into what this error means, why it occurs, and provide actionable steps to resolve it, empowering you to quickly overcome this common development hurdle and keep your projects on track.

Understanding the CodeDom Provider Error

The error “The CodeDom provider type “Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider” could not be located” points directly to a problem with how your ASP.NET application handles code compilation. CodeDom, short for Code Document Object Model, is a technology that allows programs to generate and compile code at runtime. It provides a way for .NET applications to interact with language compilers. Historically, ASP.NET applications used built-in compilers. However, with the advent of the Roslyn compilers (the .NET Compiler Platform), Microsoft introduced Microsoft.CodeDom.Providers.DotNetCompilerPlatform to allow ASP.NET web applications to leverage these newer, faster, and more robust compilers.

Specifically, the CSharpCodeProvider is the component responsible for compiling C code. When the system reports that this provider “could not be located,” it typically means one of two things: either the necessary assemblies (DLLs) for DotNetCompilerPlatform are missing from your project’s bin folder, or the web.config file is incorrectly configured, preventing the application from finding or loading the provider. This often happens in migrated projects, environments with strict security policies, or after manual file manipulations. The DotNetCompilerPlatform package, usually installed via NuGet, ensures that your application can compile code using the latest C language features, even on servers that might not have the latest Visual Studio or .NET SDKs installed globally.

This problem is particularly prevalent in ASP.NET Web Forms or MVC 5 applications that rely on runtime compilation. If the compiler provider isn’t correctly referenced or available, the application simply doesn’t know how to turn your C source code into executable instructions. Resolving this requires verifying your project’s dependencies and configuration settings, ensuring that all pieces of the compilation puzzle are present and correctly aligned.

Common Causes and Diagnosing the Problem

Several factors can lead to the “The CodeDom provider type “Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider” could not be located” error. Identifying the specific cause is the first step toward a lasting solution. One of the most frequent culprits is missing or corrupted NuGet packages. The Microsoft.CodeDom.Providers.DotNetCompilerPlatform package is essential, and if it’s not correctly installed, restored, or if its files are not deployed to the server, the application won’t find the necessary provider.

Another common cause is an incorrect or incomplete web.config configuration. The web.config file specifies which CodeDom providers your application should use. If the entries for CSharpCodeProvider or VBCodeProvider are missing, misspelled, or point to an incorrect assembly, the runtime will fail to locate the provider. This often occurs when projects are manually edited, merged, or when migrating from older .NET versions without proper configuration updates. For instance, a project might be configured to use a specific version of the provider that isn’t actually present in its dependencies.

The error “The CodeDom provider type ‘Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider’ could not be located” typically signifies that the necessary NuGet package, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, is either missing, not properly restored, or its configuration in the web.config file is incorrect, preventing the application from utilizing the Roslyn C compiler during runtime compilation.

Furthermore, issues related to the project’s target framework can also contribute. If the project targets a .NET Framework version that is incompatible with the installed DotNetCompilerPlatform package, or if there’s a mismatch between your development environment and the deployment server’s installed frameworks, you might encounter this error. Build action settings for source files, though less common, can sometimes interfere if they prevent necessary files from being copied to the output directory. It’s crucial to inspect your project’s references, ensuring that all required assemblies are correctly referenced and included in the build output. As discussed on Microsoft Learn, proper project configuration is paramount for successful application deployment and execution, especially concerning dependencies like compilers. Referencing the official .NET documentation on application configuration can provide deeper insights.

Infographic here
Step-by-Step Solutions to Resolve the Error -------------------------------------------

Resolving the “The CodeDom provider type “Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider” could not be located” error usually involves a systematic approach to check and correct your project’s dependencies and configuration. Follow these steps:

  1. Restore NuGet Packages: This is often the quickest fix.

    • Open your solution in Visual Studio.
    • Right-click on your solution in Solution Explorer.
    • Select “Restore NuGet Packages.”
    • If that doesn’t work, try “Manage NuGet Packages for Solution…” > Updates tab. Ensure Microsoft.CodeDom.Providers.DotNetCompilerPlatform is installed and up-to-date. Sometimes, uninstalling and reinstalling the package can resolve corrupted installations.

  2. Verify web.config Configuration: Ensure the compiler settings are correct.

    • Open your project’s web.config file.
    • Locate the <system.codedom> section.
    • Ensure it contains entries similar to these, pointing to the correct assembly and version (adjust version if necessary): ``` <system.codedom> </system.codedom>
    • Pay close attention to the Version and PublicKeyToken attributes, which must match the installed NuGet package.

  3. Clean and Rebuild Solution:

    • In Visual Studio, go to Build > Clean Solution.
    • Then, go to Build > Rebuild Solution. This forces all project dependencies to be re-evaluated and recompiled.

  4. Check Project References:

    • In Solution Explorer, expand your project, then expand “References.”
    • Ensure that Microsoft.CodeDom.Providers.DotNetCompilerPlatform is listed and that its “Copy Local” property is set to “True.” This ensures the DLLs are copied to your bin folder upon build. Question & Answer :
      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

    enter image description here

    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.

    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>