Question
Fixing "Could Not Find ... bin\roslyn\csc.exe" in ASP.NET MVC
Question
I am trying to run an ASP.NET MVC project retrieved from TFS source control. I added all required assembly references, and the project builds successfully without any errors or warnings.
However, when I run the application in the browser, I get this error:
Could not find a part of the path
'C:\B8akWorkspace\B8akProject\B8akSolution\B8AK.Portal\bin\roslyn\csc.exe'
I later learned that Roslyn is the .NET compiler platform, but I do not understand why my application is trying to locate bin\roslyn\csc.exe when I did not explicitly configure Roslyn or intend to use it in the project.
Why does this happen in an ASP.NET MVC application, and how can I fix it correctly?
Short Answer
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.
Concept
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.DotNetCompilerPlatformpackage is installed, but its files were not copied correctly. - The
binfolder 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.
Mental Model
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."
Syntax and Examples
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.
Step by Step Execution
Consider this simplified sequence:
- You open an ASP.NET MVC project from source control.
- Visual Studio restores some references and the main project builds.
- You run the web app.
- ASP.NET reads
web.config. - It sees that CodeDOM is configured to use
Microsoft.CodeDom.Providers.DotNetCompilerPlatform. - ASP.NET tries to launch the Roslyn compiler from:
bin\roslyn\csc.exe
- That file is missing.
- 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\roslynfolder.
Real World Use Cases
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.
Real Codebase Usage
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:
- Delete
binandobj - Restore packages
- Rebuild
- 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:
Common Mistakes
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.
Comparisons
| Concept | What it means | When it happens | Example in this issue |
|---|---|---|---|
| Build-time compilation | Visual Studio compiles your project source | During build | Solution builds successfully |
| Runtime compilation | ASP.NET compiles views or dynamic code when the app runs | When starting the site or loading a page | Browser request triggers missing csc.exe |
| Assembly reference | A DLL your project uses | Compile time and runtime | MVC assemblies may be referenced correctly |
| NuGet package content | Extra tools, targets, config, and files from a package | Restore/build/publish time | Roslyn compiler files should be copied to bin\roslyn |
Roslyn package vs framework compiler
Cheat Sheet
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.configpackages.configor 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:
- Delete
binandobj - Restore NuGet packages
- Rebuild solution
- Run application
If deploying
- Make sure
bin\roslynis included in published output.
Do not
FAQ
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.
Mini Project
Description
Create a small troubleshooting checklist for a legacy ASP.NET MVC application that fails at runtime because of a missing Roslyn compiler file. This project helps you practice identifying whether an issue comes from source code, configuration, package restore, or deployment output.
Goal
Build a repeatable diagnostic process that finds and fixes the missing bin\roslyn\csc.exe problem.
Requirements
- Inspect the project for a Roslyn CodeDOM package reference.
- Check whether
web.configcontains asystem.codedomsection usingMicrosoft.CodeDom.Providers.DotNetCompilerPlatform. - Delete the
binandobjfolders, then restore packages and rebuild. - Verify whether
bin\roslyn\csc.exeexists after rebuilding. - If the file is still missing, reinstall the package and test the app again.
Keep learning
Related questions
AddTransient vs AddScoped vs AddSingleton in ASP.NET Core Dependency Injection
Learn the differences between AddTransient, AddScoped, and AddSingleton in ASP.NET Core DI with examples and practical usage.
C# Type Checking Explained: typeof vs GetType() vs is
Learn when to use typeof, GetType(), and is in C#. Understand exact type checks, inheritance, and safe type testing clearly.
C# Version Numbers Explained: C# vs .NET Framework and Why “C# 3.5” Is Incorrect
Learn the correct C# version numbers, how they map to .NET releases, and why terms like C# 3.5 are inaccurate and confusing.