Fixing "Could Not Find ... bin\roslyn\csc.exe" in ASP.NET MVC

By the end of this page, you will understand why an ASP.NET MVC application may depend on bin\roslyn\csc.exe at runtime, even if you did not manually configure Roslyn. You will learn how NuGet package dependencies, runtime compilation, and missing build outputs can cause this error, and how to fix it using the correct package restore, reinstall, or cleanup steps.

In classic ASP.NET MVC on the .NET Framework, some applications use runtime compilation. That means parts of the app, such as Razor views or dynamically compiled code, may be compiled when the app starts or when a page is requested.

The csc.exe file is the C# compiler. In older setups, ASP.NET often used the compiler installed with the .NET Framework. But some projects include the Microsoft CodeDom Provider for Roslyn package, which tells ASP.NET to use a Roslyn-based compiler instead.

When that package is installed, the application may expect these files to exist inside the project output folder:

bin\roslyn\csc.exe
bin\roslyn\vbc.exe

So even if your project builds in Visual Studio, the web application can still fail at runtime if those Roslyn compiler files were not copied into bin\roslyn.

Why this matters

This error is usually not about your own source code being wrong. It is usually about one of these setup issues:

• NuGet packages were not fully restored after getting the project from source control.
• The Microsoft.CodeDom.Providers.DotNetCompilerPlatform package is installed, but its files were not copied correctly.
• The bin folder was cleaned, but the package targets did not run as expected.
• The project references Roslyn through configuration or package dependencies, even if you never added it manually.

In short, the application is not randomly looking for Roslyn. A package or config setting in the project is instructing ASP.NET to use it.

Think of your ASP.NET MVC app like a theater production.

• Your source code is the script.
• The build step is rehearsal.
• The runtime compiler is the stage crew making last-minute adjustments before the show starts.

Your project may rehearse perfectly in Visual Studio, but when the show begins in the browser, the stage crew is asked to use a specific tool: bin\roslyn\csc.exe.

If that tool is missing, the show cannot start, even though rehearsal looked successful.

So the problem is often not "my code does not compile." It is "the runtime expects a compiler tool that was not copied with the app."

The issue is usually caused by a NuGet package and a config entry similar to this.

Example web.config

<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:default /nowarn:1659;1699;1701" />
  </compilers>
</system.codedom>

This tells ASP.NET to use the Roslyn-based CodeDOM provider.

Example packages.config

<package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="2.0.1" targetFramework="net472" />

If this package exists, the project may expect Roslyn compiler files to be copied to the output folder.

Consider this simplified sequence:

1. You open an ASP.NET MVC project from source control.
2. Visual Studio restores some references and the main project builds.
3. You run the web app.
4. ASP.NET reads web.config.
5. It sees that CodeDOM is configured to use Microsoft.CodeDom.Providers.DotNetCompilerPlatform.
6. ASP.NET tries to launch the Roslyn compiler from:

bin\roslyn\csc.exe

1. That file is missing.
2. The app throws this runtime error.

Traceable example

Suppose your project contains:

<system.codedom>
  <compilers>
    <compiler language="c#;cs;csharp"
              extension=".cs"
              type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform" />
  </compilers>
</system.codedom>

At runtime:

• ASP.NET creates the configured compiler provider.
• That provider expects Roslyn compiler files.
• It checks the bin\roslyn folder.

This concept appears in many real maintenance tasks for older .NET web applications.

1. Getting a project from source control

A developer clones or retrieves a legacy ASP.NET MVC app from TFS, Git, or another repository. The solution builds, but runtime files from NuGet packages were not restored correctly.

2. Deploying to a server

The application works locally but fails on IIS because bin\roslyn was not deployed or was excluded during publish.

3. Cleaning build artifacts

A team deletes bin and obj folders to fix a build issue. After rebuilding, the Roslyn folder is still missing because the package installation is broken.

4. Upgrading packages

Updating MVC, Razor, or CodeDOM-related packages can change runtime compiler behavior. A mismatched package version may leave invalid config or missing files.

5. Working with Razor views

ASP.NET may compile .cshtml views dynamically. That process can trigger the Roslyn compiler dependency even if your main project already compiled successfully.

In real projects, developers usually handle this problem through a few repeatable patterns.

Guard the environment with package restore

Teams make sure NuGet restore runs automatically on every machine and build agent. This avoids missing package content after pulling from source control.

Keep package and config in sync

If web.config references Microsoft.CodeDom.Providers.DotNetCompilerPlatform, the matching NuGet package must exist and be healthy. If the package is removed, the config should also be updated.

Use clean rebuilds for environment issues

A common troubleshooting pattern is:

1. Delete bin and obj
2. Restore packages
3. Rebuild
4. Run again

This helps separate code problems from output-folder problems.

Reinstall broken packages

In older ASP.NET projects, reinstalling a package often repairs:

• missing build targets
• missing content files
• outdated binding redirects
• broken config transforms

Deployment validation

In real codebases, teams verify that publish output contains required runtime files. For this issue, they specifically check whether bin\roslyn\csc.exe exists after publish.

Error handling mindset

This is a good example of a runtime environment error, not a business logic bug. Developers learn to inspect:

1. Assuming a successful build means runtime is fully ready

A project can compile in Visual Studio and still fail when the web app starts.

Avoid it: Treat build-time and runtime as separate stages.

2. Manually copying random csc.exe files

Some developers copy a compiler from another machine or another .NET folder.

Do not fix this by copying arbitrary compiler files into bin\roslyn.

Why this is risky:

• version mismatches
• missing companion files
• harder future maintenance

Better approach: restore or reinstall the correct package.

3. Removing config without understanding it

A beginner may delete the system.codedom section to stop the error.

<!-- Removing this blindly can break runtime compilation -->
<system.codedom>
  ...
</system.codedom>

Avoid it: Only remove Roslyn-related config if you intentionally remove the package and confirm the app still works.

4. Committing bin folders to source control as a workaround

This may seem to fix the issue temporarily, but it creates messy and unreliable repositories.

commit source and package references, not generated output.

Roslyn package vs framework compiler

Error:
Could not find a part of the path '...\bin\roslyn\csc.exe'

What it usually means

• Your ASP.NET MVC app is configured to use the Roslyn CodeDOM compiler.
• The required compiler files were not copied to bin\roslyn.

Where to check

• web.config
• packages.config or project package references
• .csproj
• publish output

Typical files involved

bin\roslyn\csc.exe
bin\roslyn\vbc.exe

Common fix steps

Update-Package -reinstall Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Then:

1. Delete bin and obj
2. Restore NuGet packages
3. Rebuild solution
4. Run application

If deploying

• Make sure bin\roslyn is included in published output.

Do not

Why does ASP.NET look for bin\roslyn\csc.exe if I never added Roslyn manually?

A NuGet package or project template may have added the Roslyn CodeDOM provider automatically. Your app can depend on it even if you did not configure it yourself.

Why does the solution build successfully but fail in the browser?

The Visual Studio build and ASP.NET runtime compilation are not always the same process. The runtime may need additional compiler files that were not copied to the output folder.

Which package usually causes this behavior?

The most common one is Microsoft.CodeDom.Providers.DotNetCompilerPlatform.

Is it safe to just create the bin\roslyn folder manually?

No. The issue is not just the folder name. The correct compiler files and matching package version are needed.

Should I remove the Roslyn package?

Only if you understand why it was added and confirm your app works without it. In many cases, reinstalling or restoring the package is the safer fix.

Can this happen only on local machines?

No. It can also happen on IIS servers or during deployment if the Roslyn files are missing from published output.

How can I confirm the cause quickly?

Check whether web.config references Microsoft.CodeDom.Providers.DotNetCompilerPlatform and whether bin\roslyn\csc.exe exists after rebuilding.

• NuGet package restore — Missing package content is one of the most common causes of this error.
• ASP.NET runtime compilation — Helps explain why the error appears in the browser instead of during build.
• Razor view compilation — Views may be compiled at runtime and trigger the compiler dependency.
• web.config configuration — The compiler provider is often configured here.
• CodeDOM providers — This is the mechanism ASP.NET uses to select a compiler.
• Build output folders (bin and obj) — These folders often need to be cleaned and regenerated.
• ASP.NET MVC deployment — Publish output must include all required runtime files.
• Package version mismatch — Broken or inconsistent package versions can cause missing-file runtime errors.