The System.ComponentModel.Win32Exception: Access is denied error appears after publishing .NET 4.5 or higher applications. It references an inability to execute the command "c:\hostingspace\USERNAME\somewebsite\wwwroot\bin\roslyn\csc.exe". The two solutions that resolve the issue are to uninstall the Microsoft.CodeDom.Providers.DotNetCompilerPlatform NuGet package (which also removes the associated web.config entries) and republish, or to directly remove the system.codedom element and its contents from your website's web.config file.

This exception wraps an ExternalException with HRESULT 0x80004005 and surfaces because the application pool identity lacks execute rights on the Roslyn compiler binaries deployed to the bin/roslyn folder. The error prevents the site from starting. It is triggered by the CodeDom configuration that registers the Roslyn CSharpCodeProvider and VBCodeProvider. Both solutions eliminate the runtime attempt to launch these compilers, which most published applications do not require.

#Why This Error Occurs

The Microsoft.CodeDom.Providers.DotNetCompilerPlatform package adds Roslyn support for dynamic compilation in .NET Framework 4.5 and later projects. Upon publish, it copies csc.exe, vbc.exe, and supporting files into a roslyn subdirectory under bin and injects a system.codedom section into web.config. On Windows hosting servers the uploaded executables often receive only read permissions for the IIS user account tied to your site. When ASP.NET initializes the compilation providers at startup the Win32 layer throws the access-denied exception. The problem is specific to shared environments with locked-down ACLs and does not usually appear on local development machines or dedicated servers where you control permissions.

#Prerequisites

  • - A .NET Framework 4.5 or higher web application - Visual Studio with NuGet Package Manager - Published site exhibiting the error after deployment - FTP or file manager access to the live web.config and bin folder - Backup of the current web.config before changes

#Solution 1: Uninstall Microsoft.CodeDom.Providers.DotNetCompilerPlatform

This is the preferred method because it removes the package, the roslyn folder from future publish outputs, and the codedom configuration automatically. Your project falls back to the built-in CodeDom providers supplied by the .NET Framework.

#Step-by-Step Instructions

  • - Open the solution in Visual Studio - Navigate to Tools > NuGet Package Manager > Manage NuGet Packages for Solution - Switch to the Installed tab and locate Microsoft.CodeDom.Providers.DotNetCompilerPlatform - Select the package and click Uninstall; confirm removal of dependencies if prompted - The process automatically deletes the system.codedom section from web.config - Clean the solution, then rebuild - Republish the application to your hosting space, ensuring the bin/roslyn directory is no longer included

#Solution 2: Remove the system.codedom Element from web.config

Use this approach when you must retain the NuGet package or cannot republish from source immediately. Manually deleting the configuration entry stops ASP.NET from loading the Roslyn providers while leaving the binaries in place.

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

Open the web.config file in a text editor. Locate the system.codedom element (usually near the end, inside the configuration root) and delete the entire block including all child compiler entries. Save the file and upload it to the server. If the roslyn folder still exists in bin you may delete it manually via FTP to reduce footprint, although it is no longer referenced after the config change.

#Common Pitfalls

  • - Forgetting to clean and rebuild before republishing, leaving stale roslyn files on the server - Retaining an old web.config that still contains the codedom section after package uninstall - Manually editing web.config with incorrect XML that breaks the entire configuration - Assuming the package is required when the project performs no runtime compilation - Deploying from a publish profile that always includes all bin contents regardless of project references

#Verification and Testing

After applying either fix, restart the application by touching web.config or recycling the application pool. Request the site URL and confirm the exception no longer appears. Check any custom error logs or the Windows Event Viewer for related entries. Load pages that exercise code-behind and compiled resources to ensure normal operation. If you use FTP, verify that the bin/roslyn directory has been removed or at least no longer causes startup commands.

Choose Solution 1 for new deployments because it prevents the unnecessary binaries and configuration from being generated again. For applications that do not compile code at runtime this change reduces deployed size and eliminates a common permission vector. Keep your project dependencies minimal and test publish outputs locally before uploading to avoid recurring configuration conflicts.