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

Asked 24/10, 2015 at 15:11 Answered 11/10, 2023 at 7:35

203

It's a WebApi project using VS2015.

Step to reproduce:

Create an empty WebApi project
Change Build output path from "bin\" to "bin\Debug\"
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.

Maul answered 24/10, 2015 at 15:11 Comment(4)

May I ask why you changed your web application's output path? Thank you. – Erysipeloid 25/11, 2015 at 0:46

This exception is happening to me every time I refresh a previously ran ASP.NET MVC applicaiton during the msbuild comilation. – Ozoniferous 29/11, 2015 at 16:13

The same thing happened to me. It started after I added references to a couple of .dll libraries. I fixed it by uninstalling and re-installing the libraries. And have no idea of why this happened whatsoever.. – Bensky 28/8, 2019 at 13:54

Fixed by reverting back to \bin ... and I do this only for the entry / starting assembly ie. the exe / application. The class libs go into \bin\$(Configuration) and that is fine by them. Could not find a way to bypass this on .NET48 ASPNET webapp. – Finkle 21/4, 2022 at 13:56

153

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:

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
```

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>

Westfahl answered 8/3, 2017 at 10:1 Comment(6)

I've been stuck on "server error in '/' application" for about a day now. I am compiling a simple Hello World application in Visual Studio 2015, and deploying it to a web server, and getting this error. Removing the <compiler> lines above also made this problem go away. I'd like to know how on earth this happens and whether there's a better solution. I find it quite unbelievable that you cant deploy a hello world app in this way without hitting problems, its like MS don't do any testing :--) – Tko 23/5, 2017 at 6:26

To enable Roslyn you can see the following article Enabling the .NET Compiler Platform (“Roslyn”) in ASP.NET applications Why Roslyn compilation in ASP.NET? Enabling the new Roslyn compilers in your ASP.NET application will result in two main benefits: * Support for new language features * Potentially improved application startup/pre-compilation time – Westfahl 23/5, 2017 at 7:17

When I created a new web project, it came with those references already in place. Why are they installed by default, what is their purpose? Also to my understanding Roslyn is the new C# compiler. How does removing it not break Visual Studio? – Dian 26/9, 2018 at 2:10

@JensMander both are compilation runtimes. In IIS we need to manually enable Roslyn Compiler. Please see the link in my previous comment regarding the article 'Enabling the .NET Compiler Platform. – Westfahl 26/9, 2018 at 6:12

I've had the same error, finally updated latest package for Microsoft.CodeDom.Providers.DotNetCompilerPlatform solved for me. – Ecchymosis 4/12, 2018 at 4:35

@Westfahl the linked article only appears to take you to a Preview or github source code, which are both useless for System admins looking to make sure their Window Server can run ASP.NET sites using the code. There should be clear and consistent information on what you mean by 'hosting providers still have not upgraded their servers'. What exactly does one upgrade? – Dirt 3/6, 2019 at 4:24

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.

Elemi answered 21/1, 2016 at 12:40 Comment(12)

It isn't supposed to be in GAC. The whole point behind the Nuget approach is to have your project use a specific version of C# or VB.NET without changing anything on the host system. See this post from Damian Edwards of MSFT: blogs.msdn.microsoft.com/webdev/2014/05/12/… – Questionary 23/8, 2016 at 2:32

True as it may be, personally I dont like being forced into new approaches. moreover, i'm constantly having issues to solve when deploying projects to new envinroments when using nugets due to unmatching version and accidental updates people are doing. For me nugets are extremely annoying and time consuming. I get the pros and cons of nuget, I agree that the general idea is pretty cool, I'd still prefer to put essential dlls once on the gac and forget about them. When deploying the release version I would have this dll copied anyway – Elemi 16/9, 2016 at 13:37

These assemblies do NOT belong in the GAC, period. Placing them in the GAC will result in an eventual headache when someone who needs to maintain your code can't determine why the wrong compiler is used. – Griggs 15/11, 2016 at 22:36

-1 for Microsoft remarks. It's as if it's cool to do it these days. BTW, nugets have a lot of advantages that made them very popular which you are simply ignoring. Now imagine about what Microsoft gentlemen would think of this. – Jacobus 26/7, 2017 at 13:20

Hey, its only my opinion. I am a .net developer, I generally love Microsoft, but that is irrelevant. People in Microsoft, maybe not nice or gentelmen, have decided to make us move to nugets. this is not the place to discuss the advantages, this is a post that if you got to it there is a real chance you ran into a problem with it. I imagine, or at least hope, someone from Microsoft who sees this will try to make the system less buggy and more intuitive based on a real user input. That of course is going to happen only if he is not involved in another holly war :) – Elemi 26/7, 2017 at 13:34

@OleAlbers sounds awesome. But have you tried forking something written in c# from github lately? At least for me it wasn't as simple as it should be since I had to start figuring out the mess with the nugets. It happened with more than one or two incidents. – Elemi 7/11, 2017 at 12:41

@YuvalPerelman Microsoft do a lot of destructive stuff last 3-4 years(like destabilizing Visual studio, producing very low-quality products). Sometimes I am even praying that the whole management of development department will be fired. However it is definitely not that case! – Gloria 28/2, 2018 at 14:13

@Gloria possible. Very possible. I work with nugets my self on a daily basis for the last 5 years at least, it's not like I have a choice. But I ask you this: have you tried forking something out of github and managed to just build it recently? Have you tried using the same project that uses some nugets in 2 different solutions without sweating blood over figuring all the different dependencies? Didn't you get any of the nice obscure error messages when an update just fails and you don't know why? If the answer is yes for all of the above I can only say I envy you, that wasn't the case for me. – Elemi 28/2, 2018 at 15:54

@YuvalPerelman Yes, I had the same problems. But the source of the issue is VS developers team, nuget itself is fine! I can ask you opposite question, have you ever developed something in modern frontend, where you have a lot of different package managers: npm, bower, yarn,...? And try to build a normal project. Possibility to choice is not always helpful! – Gloria 9/3, 2018 at 7:38

@Gloria You are right. That doesn't change the fact that these issues are time consuming and demoralizing for the team who end up using it. I can give many possible solutions that Microsoft can try to implement in order to prevent these problems, and probably there is a good reason why each of my solutions would be bad. It doesn't matter. At the end of the day, I need to complete a task and that task would be completed faster and better without using nugets when its not absolutely necessary. Using GAC or just a central folder for third party DLLs never fails me and doesn't have an overhead. – Elemi 9/3, 2018 at 13:25

GAC'ing this dependency is the most awesome thing I've seen in a while. – Convert 26/3, 2019 at 13:1

It solved the urgent issue and allows me to check the root cause of this on a later moment. This is a decent solution. – Vacancy 2/5, 2019 at 7:32

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

Had the same problem.

Gloria answered 29/5, 2016 at 13:30 Comment(1)

Just be a bit careful; it overwrites the 'compilerOptions' within the web.config, so make sure you save any custom values before installing. – Spectatress 19/2, 2018 at 15:46

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

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

Ecotype answered 26/3, 2016 at 23:57 Comment(3)

Thanks for the tip re right-clicking the project's References folder to open the package manager – Sochi 29/9, 2016 at 12:52

Try to uninstall it first, then install it again in NuGet. That worked for me. – Karakalpak 11/11, 2016 at 14:11

You are a legend – Fries 19/9, 2018 at 9:11

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.

Panga answered 24/11, 2017 at 9:16 Comment(3)

I have problems with DotNetCompilerPlatform every single time I update it. – Androus 11/2, 2018 at 2:39

If you remove the version attribute, will also work and prevent the error from raise again on next update. – Brabazon 13/3, 2018 at 11:35

Same problem I just had except I had to update from 2.0.0 to 2.0.1 – Venezuela 23/10, 2018 at 10:33

Another possible solution:

➜ Restart your Visual Studio Instance with Administrator Rights

Shawnee answered 13/3, 2018 at 22:36 Comment(0)

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.

Erysipeloid answered 24/11, 2015 at 23:30 Comment(0)

Easy way - Project > Manage NuGet Packages... > Browse(tab) > in search input set this: Microsoft.CodeDom.Providers.DotNetCompilerPlatform

You can install or update or uninstall and install this compiler

Eisenach answered 22/1, 2018 at 16:16 Comment(0)

In my case, this happened when i change the permission of application folder and account IIS_IUSRS has been removed. After i re-added IIS_IUSRS (IIS Manager-> YourWebApp -> Edit Permission -> Add IIS_IUSRS) to the application folder and its worked.

Managing answered 3/8, 2017 at 8:14 Comment(1)

I had added IUSR permissions, but it was not adequate. I had to add "IIS_IUSRS" and then it worked. – Robbins 14/3, 2018 at 1:19

It stopped after publishing on the production server. The reason why it showed me this error was because it was deployed to a subfolder. In IIS i clicked right on the subfolder and excuted "Convert to application" and after this it worked.

Candelariacandelario answered 5/7, 2017 at 13:23 Comment(2)

Convert to Application was all I needed. (It was a new project that hadn't published before.) – Vannoy 7/9, 2017 at 17:37

Using a subfolder was my issue as well, so I moved to the base folder and things started working. – Tremblay 9/5, 2020 at 21:58

Here's how I resolved it:

Deleted the bin folder in the project directory.
Click on Build Solution. In VS2017(Run as Admin) > Build > Build Solution.

Vidette answered 15/5, 2018 at 10:11 Comment(0)

Then the problem came back. I uninstalled both Microsoft.CodeDom.Providers.DotNetCompilerPlatform and Uninstall-package Microsoft.Net.Compilers but no help. Then installed - no help. Cleaned project and built no help. Restarted server no help.Then I noticed the project needed not the latest one which is currently 1.0.5 but 1.0.3 as that was the error could not load the 1.0.3 version. So I installed that dll version instead and now it works.

Photocompose answered 17/6, 2017 at 2:11 Comment(1)

How did you install the dll version, if I may? – Scant 3/12, 2020 at 12:42

just uninstall the package from package manager console from command below

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

PM> Uninstall-package Microsoft.Net.Compilers

and then install it again from nuget manager

Clamant answered 19/4, 2018 at 5:25 Comment(1)

Yup, exactly. I have to do this about once a month for some reason. Just go into "Manage NuGet Packages for Solution" in VS2022, uninstall the DotNetCompilerPlatform library, then reinstall it. (Sigh.) Doing a Clean/Rebuild/etc is never enough.... – Onofredo 2/11, 2023 at 10:26

Make sure your project has fully built!

Click on 'Output' tab and make sure you don't have something like:

========== Rebuild All: 14 succeeded, 1 failed, 0 skipped =========

And open your bin folder and check to see if it's up to date.

I had a whole bunch of typescript errors that I ignored at first, forgetting that they were breaking the build and leading to there being no DLLs copied in.

Ate answered 12/12, 2018 at 21:31 Comment(0)

If you are using git, you are probably ignoring the .dll in the commit

Hyperborean answered 15/10, 2019 at 5:42 Comment(0)

ASP.NET does not search bin/debug or any subfolder under bin for assemblies like other types of applications do. You can instruct the runtime to look in a different place using the following configuration:

<configuration>
   <runtime>   
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin\Debug;bin\Release"/>
      </assemblyBinding>
   </runtime>   
</configuration>

Therapsid answered 5/8, 2016 at 20:55 Comment(0)

I had a number of projects in the solution and the web project (problem giving this error) was not set as the StartUp project. I set this web project as the StartUp project, and clicked on the menu item "Debug"->"Start Debugging" and it worked. I stopped debugging and then tried it again and now it’s back working. Weird.

Photocompose answered 29/11, 2016 at 15:51 Comment(0)

You should update the "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" and "Microsoft.Net.Compilers" packages in your project .

Poltroonery answered 5/4, 2017 at 11:11 Comment(0)

In my case, I got the error when I had my Web Application in 4.5.2 and the referenced class libaries in 4.6.1. When I updated the Web Application to 4.5.2 version the error went away.

Retroaction answered 20/6, 2017 at 2:58 Comment(1)

Got indeed the same error when installing Umbraco 8, for the wrong .Net version (needed 4.7.2) instead of 4.5.2 (default VS 2017) – Rugen 6/3, 2019 at 8:59

I was getting this error because my application pool user was set to ApplicationPoolIdentity. I changed it to a user/service account that has access to the folder and the error went away.

Stretchy answered 1/12, 2017 at 21:33 Comment(0)

Here are my findings. I also faced this problem today's morning. I just added my current user to application pool on which application was running.

Steps:

Open IIS
Click on application pool
Select your application pool on which you are getting problem
Right Click -> advanced settings
Click on three dot icon beside the identiy
Now select custom account
Give your PC user name and Password
Save

Refresh your application.. and it will start working. There was some security issue for accessing dll.

Autography answered 5/12, 2017 at 7:22 Comment(0)

If you have recently installed or updated the Microsoft.CodeDom.Providers.DotNetCompilerPlatform package, double-check that the versions of that package referenced in your project point to the correct, and same, version of that package:

In ProjectName.csproj, ensure that an <Import> tag for Microsoft.CodeDom.Providers.DotNetCompilerPlatform is present and points to the correct version.
In ProjectName.csproj, ensure that a <Reference> tag for Microsoft.CodeDom.Providers.DotNetCompilerPlatform is present, and points to the correct version, both in the Include attribute and the child <HintPath>.
In that project's web.config, ensure that the <system.codedom> tag is present, and that its child <compiler> tags have the same version in their type attribute.

For some reason, in my case an upgrade of this package from 1.0.5 to 1.0.8 caused the <Reference> tag in the.csproj to have its Include pointing to the old version 1.0.5.0 (which I had deleted after upgrading the package), but everything else was pointing to the new and correct version 1.0.8.0.

Altimeter answered 25/4, 2018 at 8:47 Comment(0)

Go to inetmgr from start command In IIS manager console choose the application folder under Default Web Site right click on that folder then Convert to Application Run the .asmx file by Enabling It solved the problem

Hepler answered 10/2, 2019 at 2:56 Comment(1)

This did it for me – Eldest 7/9, 2021 at 11:59

Add a reference to the CppCodeProvider assembly.

Bennie answered 23/5, 2019 at 14:32 Comment(0)

Regarding this error I've tried:

Cleaning and rebuilding the project
Unloading and reloading the project
Modifying the Target Framework
Modifying the Output path
Adding nuggets to the GAC
Deleting the packages uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform uninstall-package Microsoft.Net.Compilers and installing them again.

While these all seem to be valid solutions, I was only able to generate new errors and in the end, the error seems able to display when certain references/nugets are missing.

In my case, I had recently reinstalled Microsoft Office and was referencing assemblies like Microsoft.Office.Core. The new install didn't seem to include the required packages, which made it so my solution couldn't build correctly.

I was able to solve this issue by reworking my code to the point where I didn't need to reference Microsoft.Office, but could've solved it by looking up the required packages and installing them accordingly.

Seems like an unclear error message from Visual Studio.

Jermaine answered 16/8, 2019 at 9:7 Comment(0)

In My case my web project was not loaded properly ( it was showing project unavailable ) then I had to reload my web project after opening my visual studio in admin mode then everything worked fine.

Suited answered 28/8, 2019 at 10:40 Comment(0)

If you have been working on a project and this just now popped up as an error. REBOOT your computer (or server in my case) this fixed the issue for me.

Wagner answered 11/12, 2019 at 18:53 Comment(0)

I just had the same problem and it was because I moved the project location and simply needed to recreate the virtual directory.

Gilliland answered 12/12, 2016 at 13:12 Comment(0)

The exception that we ran into was not on the local but on the remote server, the Azure CI was reading it from the packages folder but the compiler versions mentioned above were not found.

To fix this we modified the project file to make it something like

It is not referencing any of the packages here directly referencing the environment variables.

This fixed the issue, however in our cases we don't use packages directly from "package.config" instead we have a separate folder to maintain version integrity across teams.

Palp answered 10/7, 2018 at 12:40 Comment(0)

Check whether the BIN folder is uploaded completely or missing in the files.

Psycholinguistics answered 16/2, 2019 at 8:44 Comment(1)

I am also facing the same issue, quite new to asp.net – Ware 25/2, 2019 at 9:53

If you see this probably you are building in release mode. For production you should publish instead of building in release mode. For local development build in debug mode.

Blatant answered 15/7, 2020 at 15:26 Comment(0)

In our case we are using ToroiseSVN and it seems by default the bin folder is not added to the sourcecontrol. So when updating the website on the production server the bin folder was not added to it, thus resulting in this exception.

To add the bin folder to SVN go to the folder on the hdd and find the bin folder. Right click it and select TortoiseSVN --> Add

Now update the repository to include the newly added files and update the production server next. All should be well now.

Bridesmaid answered 16/9, 2020 at 9:25 Comment(0)

It's 2023, and this issue is still alive and kicking in VS2022 (v17.7.4)

The solution for me was to uninstall the DotNetCompilerPlatform NuGet package, and then reinstall it.

I have to do this at least a couple of times each month.

Onofredo answered 11/10, 2023 at 7:35 Comment(0)

-2

Ensure Internet Information Services(IIS) is enabled in Windows features on your machine.

Intorsion answered 10/1, 2018 at 17:0 Comment(1)

Internet information services was disabled on my machine - I enabled it and the exception persists. – Battlement 28/7, 2018 at 16:15

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Conclusion

Make sure your project has fully built!

Recommended topics

Hot tags