CodeDom provider type "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider" cannot be located

This is a WebApi project using VS2015.

Step to play:

  • Create an empty WebApi project
  • Change build output path from "bin \" to "bin \ Debug \"
  • Run

enter image description here

Everything works fine until I changed the build path of the assembly from "bin \" to "bin \ Debug \" In fact, any output path other than "bin \" will not work.

Another additional thing: having a different exit path anywhere will work as long as I left the assembly in "bin".

Please help solve the problem. I guess this will be worth the trouble with the actual deployment.

+139
c # asp.net-web-api msbuild
Oct 24 '15 at 15:11
source share
30 answers

If your project has Roslyn links and you deploy it to the IIS server, you may receive unwanted errors on the website, as many hosting providers have not yet updated their servers and therefore do not support Roslyn.

To fix this problem, you will need to remove the Roslyn compiler from the project template . Removing Roslyn should not affect the functionality of your code. It worked great for me and some other projects (C # 4.5.2) that I worked on.

Follow these steps:

  • Remove Nuget from the following packages using the command line below (or you can use the Nuget package manager GUI by right-clicking on the root design solution and deleting them).

    PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform PM> Uninstall-package Microsoft.Net.Compilers 
  • Remove the following code from the Web.Config file and restart IIS . (Use this method only if step 1 does not 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> 

+116
Mar 08 '17 at 10:01
source share

Be careful following this answer tip. Although this solves the problem at hand, it can cause other problems at a later stage.

I have the same problem. Apparently, the .NET compiler was not loaded in 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 lovely Microsoft gentlemen have decided not to install it in the GAC for us. You can do this 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 is trying to encourage everyone to do everything with nuget, which may be fine without the random errors you encounter on the nuget system. Try to use the same project in different solutions, accidentally (or not) update one of the many threads that he uses for one of them, and if you are not lucky, you will understand what I mean when you try to build another solution . On the other hand, placing files in the GAC can also cause future problems, as 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 place the files in a central folder for third-party DLLs (even if it is strange to call a third-party compiler), which creates problems with broken links when setting up new environments. If you decide to install the dll in the GAC, be careful and remember that you did it. If you do not, download nuget for each project again and bear all the annoying errors caused by it (at least it used to be when I got tired of it and I just put the files in the GAC). Both approaches can cause you a headache and create problems, it's just a matter of what problems you prefer to deal with. Microsoft recommends using the nuget system, and as a rule, it is better to listen to it than an unknown programmer in SO, if you are not tired of the nuget system and are not used to dealing with the GAC long enough to become a better alternative. for you.

+40
Jan 21 '16 at 12:40
source share

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

Had the same problem.

+28
May 29 '16 at 13:30
source share

I have the same problem that my application worked in Vs2013 but got an error after upgrading to Vs2015.

  • In Vs2015, right-click the Project Reference folder to open the NuGet Package Manager.
  • In the "Overview" section, find "DotNetCompilerPlatform" and install the "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" lib
+19
Mar 26 '16 at 23:57
source share

I know this is an old thread, but I would like to point out a possible version of DotNetCompilerPlatform.dll, f. ex. after update. 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 a version change from 1.0.7 to 1.0.8. The new dll was already copied to the server, but I did not change the old web.config (with some special server 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 updating two lines, the error disappeared.

+15
Nov 24 '17 at 9:16
source share

According to your playback steps, I assumed that changing the output path in the application property was your only change after creating the application. The only thing that makes this change is that it tells Visual Studio to move the output builds of MSBuild to a new folder. However, at run time, ASP.Net has no idea that it should load assemblies from this new folder instead of the \ bin folder.

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

After you start working with your application, you can overclock the <system.codedom> section. If you are not using the new C # 6 syntax in your application, you can remove the Microsoft.CodeDom.Providers.DotNetCompilerPlatform application from the application; otherwise, you can add the following command line to the post-build event,

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

The new CodeDom provider is always looking 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 Visual Studio publishing tool, however, published the output builds in the \ bin folder at the deployment location, regardless of my output path. I assume that your application should still work on the actual deployment.

+10
Nov 24 '15 at 23:30
source share

The easy way - Project> Manage NuGet packages ...> Browse (tab)> in the search, enter the following: Microsoft.CodeDom.Providers.DotNetCompilerPlatform

You can install or update or uninstall and install this compiler

Dotnetcompilerplatform

+9
Jan 22 '18 at 16:16
source share

Another possible solution:

Restart your instance of Visual Studio with administrator privileges !

enter image description here

+5
Mar 13 '18 at 22:36
source share

In my case, this happened when I changed the permission of the application folder and the IIS_IUSRS account was deleted. After I again added IIS_IUSRS (IIS Manager-> YourWebApp β†’ Change permission β†’ Add IIS_IUSRS) to the application folder and its work.

+4
Aug 03 '17 at 8:14
source share

He stopped after publishing on a production server. The reason she showed me this error was because it was deployed to a sub folder. In IIS, I right-clicked in a subfolder and extorted "Convert to Application", after which it worked.

+3
Jul 05 '17 at 13:23
source share

I had several projects in the solution, and the web project (the problem with this error) was not set as a StartUp project. I installed this web project as a StartUp project and clicked on the menu item "Debug" β†’ "Start Debugging" and it worked. I stopped debugging, and then tried again, and now am back. Weird

+2
Nov 29 '16 at 15:51
source share

Here's how I solved it :

  1. Deleted the bin folder from the project directory.
  2. Click on Build Solution . In VS2017 (Run as administrator)> Build> Build Solution .
+2
May 15 '18 at 10:11
source share

ASP.NET does not look for bin/debug or any bin subfolder for assemblies similar to other types of applications. You can specify the runtime elsewhere using the following configuration:

 <configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="bin;bin\Debug;bin\Release"/> </assemblyBinding> </runtime> </configuration> 
+1
Aug 05 '16 at 20:55 on
source share

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

+1
Apr 05 '17 at 11:11 on
source share

Then the problem came back. I uninstalled Microsoft.CodeDom.Providers.DotNetCompilerPlatform and Uninstall-package Microsoft.Net.Compilers but without help. Then I installed it - it will not help. We cleaned the project and built without help. Restarting the server did not help. Then I noticed that the project does not need the very last one, which is currently 1.0.5, but 1.0.3, since in this case the error could not load version 1.0.3. So I installed this version of the DLL, and now it works.

+1
Jun 17 '17 at 2:11
source share

In my case, I got an error when I had my web application in 4.5.2 and reference classes in 4.6.1. When I upgraded the version of the web application to version 4.5.2, the error disappeared.

+1
Jun 20 '17 at 2:58
source share

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.

+1
Dec 01 '17 at 21:33
source share

Here are my findings. This morning I ran into this problem. I just added my current user to the application pool on which the application was running.

Steps:

  • Open IIS

  • Click on application pool

  • Select the application pool for which you are getting problems.

  • Right Click -> Advanced Settings

  • Click the three dots icon next to the id.

  • Now select a user account

  • Enter username and password for your PC

  • Save

Update your application .. and it will start working. There was some security issue to access the DLL.

+1
Dec 05 '17 at 7:22
source share

just remove the package from the package manager console from the command below

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

PM> Uninstall Microsoft.Net.Compilers Package

and then install it again from Nuget Manager enter image description here

+1
Apr 19 '18 at 5:25
source share

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

  • In ProjectName.csproj make sure that <Import> for Microsoft.CodeDom.Providers.DotNetCompilerPlatform present and points to the correct version.

  • In ProjectName.csproj make sure that the <Reference> for Microsoft.CodeDom.Providers.DotNetCompilerPlatform present and points to the correct version, both in the Include attribute and in the child <HintPath> .

  • In this web.config project, make sure that the <system.codedom> tag is <system.codedom> and that its child <compiler> tags have the same version in their type attribute.

For some reason, in my case, updating this package from 1.0.5 to 1.0.8 led to <Reference> in .csproj having an Include value indicating the old version 1.0. 5 .0 (which I deleted after updating the package), but everything else pointed to the new and correct version 1.0. 8 .0.

+1
Apr 25 '18 at 8:47
source share

Make sure your project is fully built!

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

========== Rebuild everything: 14 completed successfully, 1 failed, 0 skipped =========

And open the folder with the bin tank and check if it is updated.

I had a whole bunch of typescript errors that I initially ignored, forgetting that they broke the assembly and led to the fact that there were no copied DLLs.

+1
Dec 12 '18 at 21:31
source share

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

0
Dec 12 '16 at 13:12
source share

Just select the "Create" menu to clear the project name to fix the error.

0
Nov 04 '17 at 5:56 on
source share

The exception we encountered was not on the local, but on the remote server, CI Azure read it from the package folder, but the above versions of the compiler were not found.

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

There are no links to any of the packages that directly reference environment variables.

This solved the problem, however in our cases we do not use packages directly from "package.config", instead we have a separate folder to ensure version integrity between the commands.

0
Jul 10 '18 at 12:40
source share

Go to inetmgr from the run command. In the IIS Manager console, select the application folder in the "Default Web Site" section, right-click this folder, then "Convert to Application". Run the .asmx file by activating it. This solved the problem.

0
Feb 10 '19 at 2:56
source share

Make sure the BIN folder is fully loaded or missing from the files.

0
Feb 16 '19 at 8:44
source share

Add a link to the CppCodeProvider assembly.

0
May 23 '19 at 14:32
source share

Regarding this error, I tried:

  • Cleaning and rebuilding a project
  • Unloading and reloading a project
  • Change in target structure
  • Change output path
  • Adding Nuggets to the GAC
  • Uninstall uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform uninstall-package Microsoft.Net.Compilers and reinstall them.

Although they all seem to be the right solutions, I was only able to generate new errors , and in the end, the error may appear when there are no specific links / nuances.

In my case, I recently reinstalled Microsoft Office and referenced assemblies such as Microsoft.Office.Core. The new installation did not seem to include the necessary packages, so my solution could not be built correctly.

I was able to solve this problem by redesigning my code to such an extent that I did not need to reference Microsoft.Office, but I could solve this problem by looking at the necessary packages and installing them accordingly.

It seems like an obscure error message from Visual Studio.

0
Aug 16 '19 at 9:07
source share

In my case, my web project was not loaded properly (it showed the project inaccessible), then I had to restart my web project after opening my visual studio in administrator mode, then everything worked fine.

0
Aug 28 '19 at 10:40
source share

Make sure IIS is enabled in the Windows features on your computer. enter image description here

-one
Jan 10 '18 at 17:00
source share



All Articles