Roslyn: Could not find file 'XXX\bin\roslyn\csc.exe'.

[Sc0tTyXL]

Version Used:
DotNetCompilerPlatform: 1.0.2.0 and 1.0.3.0
Visual Studio: 2015
Windows 10

Steps to Reproduce:
Project containing a Web site project, a Class library project, a Unit test project and a Windows form project.
(Untested but I suspect a simple Web project + Class library will have the same issues)

1. Check bin\roslyn\ folder is not empty
2. Make sure the Solution won't be able to build the Test or Windows form project.
   A simple compile error should do the trick
3. Build the solution (must fail)
4. The bin\roslyn\ folder is empty

Expected Behavior:
Expect the roslyn compiler to always be there after a successful build.

Actual Behavior:
A rebuild of the Web site project is required to get the Roslyn compiler in the bin\roslyn\ folder. A normal build will not bring back the Roslyn compiler.

[jasonmalinowski]

Sounds like a project system issue somewhere.

[Pilchie]

@jaredpar is this related to the NuGet package that pulls in the Roslyn compiler for WebSites? Can you help redirect?

[jaredpar]

Yes this is for the Asp.Net Roslyn package. CC @Jinhuafei

[Hilgo]

I am also facing this problem with the project not being able to find 'bin\roslyn\csc.exe', saw some tips in how to solve them, but in my case, this problem sometimes stopped happening when i rebuild and initialize the project a couple times, only to show up again later, when i make changes in my application.

I know this is not linked to this problem, i just wanted to know where to look for it, i guess is something related to IIS and my ApplicationPool in my machine.

[Pilchie]

@Jinhuafei what's the right place for this to be reported/investigated?

[Sc0tTyXL]

@Hilgo I don't think it has anything to do with IIS. It would be very strange for IIS to not have VS.net put files in the bin folder. Also, a rebuild fixes the issue and the issue stays away until any non-web project fails to compile.

It seems that 1.0.3. has the same issue as well, I've updated my post.

[Hilgo]

@Sc0tTyXL Yes, thanks for the response, i'll keep an eye in the bin folder for roslyn in the future.

[Jinhuafei]

CodeDOM Providers is not open source yet, so I'll open a bug in internal TFS and take a look at the issue. Will keep you posted through this issue.

[Jinhuafei]

@Sc0tTyXL @Hilgo Is it possible to share a simple repro solution with me? I tried both web site project and web app project with a uncompilable class lib project, but didn't see the issue you mentioned.

[Hilgo]

@Jinhuafei , i wouldn't know where to start to isolate the problem to do a repro solution, the solution i work with has a lot of libraries and is not happening anymore, rebuilding the solution worked for me and since that, roslyn folder is always there.

[Sc0tTyXL]

I tried to create a new solution and make it 100% reproducible but sadly I can't.

The only thing I can say for certain is that when I empty the Roslyn folder manually, a normal build then never fills the folder, a rebuild is always required.

I suspect that something else is clearing the folder which would explain why I can't reproduce it in a empty solution.

[Jinhuafei]

In web app project, DotNetCompilerPlatform nupkg uses msbuild system to copy Roslyn compiler bits to the bin folder. If Roslyn bits somehow is deleted, you need to build the project in order to get Roslyn compiler bits back. Be aware of the msbuild optimization. It won't compile the project, if none of the files is touched in that project. In this scenario, you have to force a rebuild.

So this doesn't look like an issue to me. @Sc0tTyXL @Hilgo Do you mind closing this thread?

[haydenhancock]

@Jinhuafei This is still an issue for those of us that are using the MSBuild step in Team Foundation Server. I am using TFS 2015 with Update 3 and it appears that the bits for roslyn are put into the bin directory, instead of the bin/roslyn directory. This causes an issue when you try to deploy the app to IIS.

What's interesting is that when building the project locally, it seems to work as expected. The roslyn bits are created in the bin/roslyn directory. I am sure the obvious answer is to just use the Visual Studio build step. Well, unfortunately, we don't believe installing Visual Studio on a build server is the answer.

This Stack Overflow was helpful but unfortunately it just copies the bits into the correct folder so now we have duplicate roslyn files in both the bin and bin/roslyn directories.

[jaredpar]

@Jinhuafei does the DotNetCompilerPlatform nuget use csc directly or does it drive compilation via MSBuild. If it's the latter then that would explain the behavior @haydenhancock is seeing. Also means we likely need to change the package to account for this.

Well, unfortunately, we don't believe installing Visual Studio on a build server is the answer.

Very much agree. Should not be required.

[haydenhancock]

@jaredpar @Jinhuafei Just for the record, I did upgrade the packages to the latest versions for:

• Microsoft.CodeDom.Providers.DotNetCom to v1.0.3
• Microsoft.Net.Compilers to v1.3.2

Some of the people mentioned that this resolved their issue but it did not resolve mine. Is there anything else I can do to prevent these 26 dlls from being built in the bin directory as a temporary workaround?

The following items are found in my csproj file (using the default MVC template in Visual Studio 2015:

<Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.3\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.3\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
<Import Project="..\packages\Microsoft.Net.Compilers.1.3.2\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.1.3.2\build\Microsoft.Net.Compilers.props')" />

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild"> <PropertyGroup> <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText> </PropertyGroup> <Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.1.3.2\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.Net.Compilers.1.3.2\build\Microsoft.Net.Compilers.props'))" /> <Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.3\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.3\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" /> </Target>

[Jinhuafei]

@jaredpar DotNetCompilerPlatform is only for runtime compilation(e.g. aspx/cshtml/global.asax etc..) and it calls Roslyn compiler under bin\roslyn directly. All its nupkg installation steps are just to make sure Roslyn compiler assemblies copied to bin folder.

@haydenhancock Thanks for the link. The problem seems caused by different definition of $(OutDir) on the CI machine. I'll take a look and see what we can do.

[jaredpar]

@Jinhuafei

and it calls Roslyn compiler under bin\roslyn directly

Great. That removes a potential bug I was worried we may have here.

[ceyhunn]

Could not find file "(_project-path_)/bin\roslyn\csc.exe", because of both windows and linux slashes , but there exists this file...

Please help me how I fix this problem?
I am using Archlinux, Mono Develop 6.2

[haydenhancock]

@Jinhuafei Definitely something with the OutDir. Here is my MSBuild argument in the MSBuild step in my version of TFS.

/p:OutDir=$(Build.ArtifactStagingDirectory)

Is there a way I can prevent the dlls for roslyn from being in the bin folder?

[venky76v]

Why do we need this roslyn folder in the bin folder? what does it do?

[Jinhuafei]

@venky76v It is for asp.net dynamic compilation.

[venky76v]

Hi Jin, Thanks for your reply. Why is the roslyn folder copied to the bin folder on the IIS server where the app is installed. I mean, is there a real need for it? We started getting errors on IIS because of the folder and when we uninstalled a couple of nuget packages, and re-deployed, the app started working again.
Regards,
Venky

[Jinhuafei]

When the first request hits the IIS, asp.net will start dynamic compilation which involves Codedom provider configured in web.config. And if you are using DotNetCompilerPlatform nupkg, it needs Roslyn compilers to do the compilation which is under bin/Roslyn folder(we hardcoded the path, cuz it's not part of the OS).

BTW, DotNetCompilerPlatform is open sourced now. If you have any issue, feel free to open an issue on this repo.

[venky76v]

Hi Jin, Thanks again for you kind reply. Makes perfect sense. Am I correct to say that VS 2015 will automatically add these packages when you create a new project targeting framework 4.5 onwards? And we can remove this package on our discretion? As you say "_DotNetCompilerPlatform is only for runtime compilation(e.g. aspx/cshtml/global.asax etc..) and it calls Roslyn compiler under bin\roslyn directly. All its nupkg installation steps are just to make sure Roslyn compiler assemblies copied to bin folder._", if any of cshtmls use any new C# features, then I reckon this needed.

What alarmed us when we looked into the bin folder, we started seeing this new folder roslyn under bin folder which was not there on our other projects that target 4.0. Also, I started to wonder why do I need this folder with c# and vb compilers exe. In my opinion, you shouldn't see compilers shipped with your binaries into Production. Frameworks should provide any run time requirements that your binaries ask for. Am I right in thinking this way?

Thanks,
Venky

[Jinhuafei]

Roslyn compiler provides a lot of benefits compared to old compilers. (check out this blog)

Yes, in VS 2015 we updated web application project template to include DotNetCompilerPlatform nupkg. If you don't need it, you can definitely remove this nupkg, and the app will switch back to use the old compilers.

Your thoughts make sense. However, shipping assemblies through .NET Framework has a lot of drawbacks. e.g. release cycle is too long, the new Framework won't be on all the servers, etc.. We see more benefits to ship products through NuGet. That's the reason we shipped DotNetCompilerPlatform as a Nuget package.

[venky76v]

Hi Jin,

Thanks again for your reply. Can I ask, if we un-install this nuget package, would we still be able to use new C# features on razor views? I mean, we will have the latest .NET framework installed on the target servers so before I want to suggest to our team to not use the package, I want to confirm that by removing this package, we should be able to use the latest features the language has to offer.

Thanks,
Venky

[Jinhuafei]

If you are using C# 6 features in the views, then you have to keep DotNetCompilerPlatform nupkg in your project. The compiler shipped with .Net Framework only supports C# 5.0

[venky76v]

Thanks Jin. Just one last question. From a security perspective, is it any risk to have executables in your binaries folder if the code with the roslyn is shipped to Production? I mean, have not other customers raised these concerns?

[Jinhuafei]

The product was reviewed by internal security team, and they didn't have any concern. So far I haven't heard anything about this from other customers.

[fabsenet]

We have a TFS2012 build server building our website and after installing the packages, the build is no longer "copy&pasteable" to an iis folder, because, all the roslyn files are no longer in the subfolder "bin/rosly/" but they are all in "bin/":

final location of csc.exe in drop folder is:
\server\buildresults\buildname\buildnameWithDate\ConfigurationName_PublishedWebsites\WebProject\ bin

but the executing website expects that it should have been there:
\server\buildresults\buildname\buildnameWithDate\ConfigurationName_PublishedWebsites\WebProject\ bin\roslyn

(the content of "_PublishedWebsites" gets deployed as is)

So question for me is:

• Can I teach it to not flatten the folder and keep the roslyn sobfolder in bin?
• Or can I teach it to take the csc.exe from bin directly?
• Can I setup a full precompilation with roslyn to avoid compiling (and the need for roslyn) on the production machine altogether?

[Jinhuafei]

The root cause of the issue is the CodedomProvider copies Roslyn assemblies to $(OutDir)Roslyn folder which is supposed to be the bin folder under your web application. However on your build server, $(OutDir) points to a different location. You can try the workaround mentioned on this SO thread. I opened an issue on CodedomProvider repo and will fix it.

[haydenhancock]

@fabsenet All of those "answers" in the SO thread aren't very elegant in my opinion and a lot of them didn't even work for me. What I ended up doing is using PowerShell to basically "clean" the output directory. My basic steps in my PowerShell task are:

• set bin directory
• remove all items
• copy all dlls
• copy roslyn folder

Let me know if you are interested in the script and I will send it over.

[dlarkin77]

@haydenhancock I've been fighting with the answers in that SO thread and so far none of them are working for me. Could I get a look at your Powershell script?

[haydenhancock]

@dlarkin77 Take a look at the script below. The only thing you should need to change is the location of the bin directory. Let me know if you have any questions.

Clean-Project.zip

[dlarkin77]

@haydenhancock Excellent. Thanks very much.

[coder-zzo]

I encounter the problem on Apache 2 with mod_mono in raspberry 2.
I followed a stackoverflow post to added below into vHost config

MonoSetEnv [your-host-name] MONO_IOMAP=all

and reload apache 2. The problem was solved.
But got another problems. Apparently mono is too incomplete to .net framework

[pvcove]

I wrestled with this problem for at least two hours, and I'm referring specifically to the message in the title of this page. The next day I installed the latest Visual Studio updates for Mac and the problem went away....I didn't do a thing to fix it.

Coincidentally, I discovered that the latest release of VS 2017 for Mac became available the very day I performed my VS updates. That said, I recommend installing the latest updates to your Visual Studio 2017 Community for Mac. The release that fixed my problem is Visual Studio for Mac 7.1.0.1297. Refer to the link below

https://www.visualstudio.com/en-us/news/releasenotes/vs2017-mac-relnotes

[ItWorksOnMyMachine]

I upgraded VS2017 to Release 2 and performed a bunch of nuget updates and got this problem. I undid all the changes and then just upgraded the Microsoft.CodeCom.Providers.DotNetCompilerPlatform from 1.0.5 to 1.0.6. After the upgrade I stopped getting a roslyn folder in my bin folder. I reverted to 1.0.5 and started getting the folder again.

[pvcove]

I encountered my errant condition on my Mac. Running VS 2017 Community for Mac OSx. May I ask, ItWorksOnMyMachine, did you experience the error on a Mac or Windows?

Cheers Everyone!

[pauledrupt]

same here, reverted to 1.0.5 and all ok

[ItWorksOnMyMachine]

My issue is on Windows. It was happening on my local dev machine, on our build server , and ultimately on the server hosting the deployed website in iis.

[fonbrauzen]

same issue on 1.0.7, currently reverted on 1.0.5

[Jinhuafei]

@fonbrauzen would you please provide more details on this thread?

[Kash3580]

remove

.....................

[hendrikbar]

Upgrading to Microsoft.CodeDom.Providers.DotNetCompilerPlatform to 1.08 fixed it for me

[eman1986]

installing Microsoft.Net.Compilers solved my problem

[glmblue]

I found that installing dsx's Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix package worked for me:

https://www.nuget.org/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix/

[wpsmmb]

Another problem in non ASP.NET-projects is the build target changed in 1.0.6, 1.0.7, 1.0.8:

<Target Name="CopyRoslynCompilerFilesToOutputDirectory" AfterTargets="CopyFilesToOutputDirectory">
    <Copy SourceFiles="@(RoslyCompilerFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" ContinueOnError="true" SkipUnchangedFiles="true" Retries="0" />
    <ItemGroup  Condition="'$(MSBuildLastTaskResult)' == 'True'" >
      <FileWrites Include="$(WebProjectOutputDir)\bin\roslyn\*" />
    </ItemGroup>
</Target>

This will copy the compiler to the path 'C:\bin\roslyn' for non ASP.NET-projects. The older build target shipped with 1.0.5 works fine. [With some magic on private fields _compilerSettings and _compilerFullPath.]

<Target Name="CopyRoslynCompilerFilesToOutputDirectory" AfterTargets="CopyFilesToOutputDirectory">
    <Copy SourceFiles="@(RoslyCompilerFiles)" DestinationFolder="$(OutDir)roslyn" ContinueOnError="true" SkipUnchangedFiles="true" />
</Target>

[chakrapani2000]

changing compiler .net version from 4.5 to 4.7 worked for me

[Andrew-Bx]

Since I hit this issue today, I'll add my observation in case it can help anyone else.
I was having inconsistent results trying to isolate why I sometimes hit this issue (bin\roslyn not created) and sometimes didn't. For me it made a difference whether I reloaded the project in VS after restoring NuGet packages.

e.g. 1
1) delete packages folder
2) open VS
3) rebuild
4) observe that NuGet packages are restored, but bin\roslyn not created
5) unload project
6) reload project
7) rebuild
8) observer that bin\roslyn has been created

e.g. 2
1) packages folder already populated
2) open VS
3) rebuild
4) observe that bin\roslyn folder is created
5) delete and restore packages
6) rebuild
7) observer that bin\roslyn folder is created

I tried comparing the detailed build output from a working and non-working case, but couldn't really pin it down. I think the first difference is that when it works, the output shows:

1>CopyAllFilesToSingleFolderForPackageDependsOn = 
1>      ;
1>      
1>      RoslynCompilerFilesToPublish;

But when it doesn't work, 'RoslynCompilerFilesToPublish' isn't listed.

Later, in the non-working case, the CopyRoslynCompilerFilesToOutputDirectory target doesn't list any SourceFiles to copy.

tl;dr
Try reloading the project in VS and then rebuilding.

[playalien]

This was happening to me today. AndrewB-Titian described it perfectly. This has never happened to me before. I recently updated VS. Maybe that caused it.

[farhikhan]

AndrewB-Titian explained it so well. Thanks a lot!

[Vikas-Rakuten]

Thanks, @AndrewB-Titian for explaining in detail. I am facing a similar issue today where 'roslyn' folder is missing in 'bin' folder after publishing for the first time but subsequent publish works fine. Any solution to make it work at the first time?

[yuliia-h]

Большое спасибо! Все получилось, удалила пакет Microsoft.CodeDom.Providers.DotNetCompilerPlatform затем снова установила и все, порядок!!!

[abu18saud]

I need a video about this solution please.
please send me with: [email protected]

[ItWorksOnMyMachine]

From Package Manager Console, simply run the following command.

update-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform - r

[playalien]

So I had the latest DotNetCompilerPlatform installed and that didn't work. I did try ItWorksOnMyMachine's suggestion and that worked.