ASP.NET + Roslyn Compiler Exit Issue (VBCSCompiler.exe fails to release file locks during Rebuild)

[sujaysarma]

First noticed in Visual Studio 2017, 15.3.0, Preview 7.0 (also exists in VS 2017, 15.3.1 Preview 1.0) ( @CyrusNajmabadi : This issue is being filed as per our email thread on this issue)   Repro:

1. Open VS
2. Create a new Web Application Project -- I used WebForms (classic). Target .NET Framework 4.7
3. Check that web.config has entry for system.codedom > compilers
4. Right-click any asp.net file that can be viewed or navigated to (say /Index or /default.aspx) and do a "View in browser". Browser can be anything, I have used both Google Chrome as well as MS Edge. You don't have to do anything there, just leave the browser open as you would during  a develop with live changes kind of thing.
5. Back to VS, right-click on the web app project, and do a "Rebuild" -- not a Build.. a Rebuild. 

  You will hit this error with the following attributes:   6 messages about failure to DELETE Roslyn assemblies:   C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(4909,5): warning MSB3061: Unable to delete file "...\bin\roslyn\FILENAME". Access to the path '...\bin\roslyn\FILENAME' is denied.   The following files are mentioned:

• Microsoft.CodeAnalysis.CSharp.dll
• Microsoft.CodeAnalysis.dll
• Microsoft.CodeAnalysis.VisualBasic.dll
• Microsoft.DiaSymReader.Native.amd64.dll
• System.IO.Compression.dll
• VBCSCompiler.exe

  7 messages about failure to COPY Roslyn assemblies:   C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(4405,5): error MSB3021: Unable to copy file "...\packages\Microsoft.Net.Compilers.2.3.1\tools\FILENAME" to "bin\roslyn\FILENAME". Access to the path 'bin\roslyn\FILENAME' is denied.   The following files are mentioned:  

• System.Collections.Immutable.dll
• System.IO.FileSystem.dll
• System.IO.FileSystem.Primitives.dll
• System.Reflection.Metadata.dll
• System.Security.Cryptography.Algorithms.dll
• System.Security.Cryptography.Primitives.dll
• System.ValueTuple.dll

  After this problem is hit, every build after that FAILS.    They seem to be held in lock by the "VBCSCompiler.exe" process. If I "end task" this from Task Manager, then I can build again. 

[Pilchie]

Also tagging @jinhuafei.

[Jinhuafei]

This is fixed in Microsoft.CodeDom.Providers.DotNetCompilerPlatform nupkg 1.0.7 version

[sujaysarma]

@Jinhuafei - Confirming the bug is fixed in 1.0.7.

[aside] The fix is not apparent in a package upgrade scenario if the app is already running under IISExpress. The lock error is thrown (because it is running with the 1.0.5 version). You have to manually exit/kill VBCSCompiler.exe and then do the clean+build / rebuild to see the fix.

Not sure if there something you can add to the package upgrade command-set to get it to recycle or restart IISExpress? I guess that has other challenges in other scenarios... [/aside]

[esond]

Confirming that this issue was resolved in my three ASP.NET applications after upgrading the following packages Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.5 => 1.0.7, but with one catch.

Make very sure that you have the correct version of Microsoft.Net.Compilers installed. Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.7 depends on Microsoft.Net.Compilers 2.1.0. In my case, I had inadvertently updated Microsoft.Net.Compilers to a newer version at some point, which caused two separate VBCSCompiler processes to launch, and still encountered the same issue.

After uninstalling both packages, and then reinstalling Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.7 (which installed the correct version of Microsoft.Net.Compilers) the issue was resolved.

[jcouv]

Glad to hear this is resolved. I'll go ahead and close the issue. Feel free to re-open if that's not the case. Thanks

[beflint]

Have this same problem with VS2015 Update 3. Scenario is to first clean/build solution, Start without Debugging, Close web page, attempt to clean solution which results in 12 "Unable to delete file ... Access to path is denied. The only way to resolve is close VS2015 then reopen it. MSBuilg.log.txt

---

Nuget config is: Microsoft.Net.Compilers 2.3.2 Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.05 Had to downgrade from 1.0.7 because of previously posted problems with 1.0.7.

---

The previous problem with 1.0.7 was that it prevented me from Publishing the project (re: #21340).

[zurichero]

Still the same problem... :-( Microsoft.Net.Compilers 2.4.0 Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.08

Re-/installed both packages... still the same problem from time to time. only solution is to kill the process VBCSCompiler.exe

[esond]

@beflint @zurichero

Did you guys try using the exact Microsoft.Net.Compilers package version that Microsoft.CodeDom.Providers.DotNetCompilerPlatform installs as a dependency? See my previous comment. I had the same issue when I was using a newer version of Compilers than DotNetCompilerPlatform had listed specifically as a dependency.

[Jinhuafei]

@zurichero the latest version of DotNetCompilerPlatform will try to kill VBCSCompiler.exe if it fails to copy Roslyn bits. Do you have msbuild log that you can share?

[beflint]

Jinhauafei ... there is log attached to my Oct 3 comment.

[beflint]

Flamtap, I am current running following versions in my solution: -Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.5 -Microsoft.Net.Compilers.2.3.2 Was previously running following version but had to downgrade to 1.0.5 because VS2015 would not let me publish: Downgrade allowed me to publish, but the Roslyn compiler problem still persisted. -Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.7 -Microsoft.Net.Compilers 2.3.2

[ghost]

Hi! Why did you close it? It is often reproduced on my VS 2017 and TFS 2017. In my pc when I try to delete package folder after closing VS NetCompiler folder still locked. Ok, no problem, I may going to Task Manager. But what can I do in TFS???

[Jinhuafei]

@Sm1le291 what the version of Microsoft.CodeDom.Providers.DotNetCompilerPlatform nupkg are you using in your project? 1.0.8 version should already fix the problem.

[WimBoom]

@Jinhuafei i can reproduce this with: Microsoft.CodeDom.Providers.DotNetCompilerPlatform => 1.0.8 Microsoft.Net.Compilers => 2.4.0

For now I use the follow prebuild event (as workaround)

tasklist /FI "IMAGENAME eq VBCSCompiler.exe" 2>NUL | find /I /N "VBCSCompiler.exe">NUL if "%ERRORLEVEL%"=="0" (taskkill /IM VBCSCompiler.exe /F) else (verify >NUL)

[Jinhuafei]

@WimBoom do you have repro steps?

[WimBoom]

@Jinhuafei I have sorted it out further the problem, maybe it is a third party nuget. With this msbuild in the target file:

This step copy files from nuget package folder "APPFiles" to the webproject root folder. The nuget bin folder have a roslyn folder in the bin (copy APPFILES\bin\roslyn* to webprojectroot\bin\roslyn*). This causes maybe a conflict of usage. For now I will attempt a fix for this third party nuget.

[Jinhuafei]

@WimBoom there is a task, KillProcess, defined in Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props. You can use that to kill VBCSCompiler.exe.

[WimBoom]

@Jinhuafei Thanks!

[aliostad]

Having this problem now constantly :/

[Jinhuafei]

@aliostad do you have msbuild log that I can take a look?

[aliostad]

Not sure it is exactly the same issue. Essentially when creating Cloud Service packages in VS2017 and VS2015 from a brand new cloud project created in VS 2017, rosylin folder does not get copied.

I uninstalled 2 Rosylin related packages and issue gone.

Is this the same problem? If so repro is very easy.

[Jinhuafei]

What version of Microsoft.CodeDom.Providers.DotNetCompilerPlatform nupkg are you using? I saw the issue in Cloud Service project last year, but 1.0.8 version should fix the problem.

[aliostad]

@Jinhuafei template installs versions that do not work. And you do not notice it until you deploy since everything locally works. Then to find out you have to turn RDP on, and then find out and dig out.

Default template brings only Microsoft.Net.Compilers and not Microsoft.CodeDom.Providers.DotNetCompilerPlatform hence I started trying all these versions from 2.0, 2.0, etc and finally 2.6.1. With 2.6.x rosylin folder was being copied but I was getting a different error on the server stating the compilation failed.

This is bad, really bad. I wasted a day on this.

[Jinhuafei]

Sorry for that. The template will be updated in the coming VS2017 update.

[llyons]

We have the same issue and have the following nuget packages in play for our solution.

package id="Autofac" version="4.6.2" targetFramework="net461" /> package id="Autofac.WebApi2" version="4.1.0" targetFramework="net461" /> package id="Common.Logging" version="3.4.1" targetFramework="net451" /> package id="Common.Logging.Core" version="3.4.1" targetFramework="net451" /> package id="Common.Logging.NLog40" version="3.4.1" targetFramework="net451" /> package id="EntityFramework" version="6.2.0" targetFramework="net451" /> package id="FluentValidation" version="7.4.0" targetFramework="net451" /> package id="Humanizer.Core" version="2.2.0" targetFramework="net461" /> package id="Microsoft.AspNet.Cors" version="5.2.3" targetFramework="net461" /> package id="Microsoft.AspNet.Mvc" version="5.2.3" targetFramework="net451" /> package id="Microsoft.AspNet.Razor" version="3.2.3" targetFramework="net451" /> package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.0" targetFramework="net451" /> package id="Microsoft.AspNet.WebApi" version="5.2.3" targetFramework="net451" /> package id="Microsoft.AspNet.WebApi.Client" version="5.2.3" targetFramework="net451" /> package id="Microsoft.AspNet.WebApi.Core" version="5.2.3" targetFramework="net451" /> package id="Microsoft.AspNet.WebApi.Cors" version="5.2.3" targetFramework="net461" /> package id="Microsoft.AspNet.WebApi.HelpPage" version="5.2.3" targetFramework="net451" /> package id="Microsoft.AspNet.WebApi.Owin" version="5.2.3" targetFramework="net461" /> package id="Microsoft.AspNet.WebApi.WebHost" version="5.2.3" targetFramework="net451" /> package id="Microsoft.AspNet.WebPages" version="3.2.3" targetFramework="net451" /> package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.8" targetFramework="net451" /> package id="Microsoft.CSharp" version="4.4.1" targetFramework="net451" /> package id="Microsoft.Net.Compilers" version="2.6.1" targetFramework="net451" developmentDependency="true" /> package id="Microsoft.Owin" version="3.1.0" targetFramework="net461" /> package id="Microsoft.Owin.Cors" version="3.1.0" targetFramework="net461" /> package id="Microsoft.Owin.Host.SystemWeb" version="3.1.0" targetFramework="net461" /> package id="Microsoft.SqlServer.Types" version="10.50.1600.1" targetFramework="net451" /> package id="Microsoft.Web.Infrastructure" version="1.0.0.0" targetFramework="net451" /> package id="Newtonsoft.Json" version="10.0.3" targetFramework="net451" /> package id="NLog" version="4.0.0" targetFramework="net451" /> package id="NPoco" version="3.9.3" targetFramework="net461" /> package id="NPoco.StoredProcedures" version="1.0.5224.36605" targetFramework="net451" /> package id="NUnit" version="3.9.0" targetFramework="net451" /> package id="Owin" version="1.0" targetFramework="net461" /> package id="Swashbuckle.Core" version="5.6.0" targetFramework="net461" /> package id="System.Diagnostics.DiagnosticSource" version="4.4.1" targetFramework="net451" /> package id="ValueInjecter" version="3.1.1.5" targetFramework="net461" /> package id="WebActivatorEx" version="2.2.0" targetFramework="net461" />

Still after each build, the vbcscompiler.exe has files locked that prevent us from performing the next build (we are using a CI build system).

What can we do to fix this?

[Jinhuafei]

@llyons Can you provide more details about the issue? The vbcscompiler.exe under bin\Roslyn is only used when you precompile your web app and it is copied to the web app folder. You CI server reuses one folder for a web app? And also the default idle time of vbcscompiler.exe is 10 secs. If it's not short enough for you, you can change it through environment variable VBCSCOMPILER_TTL. (unit is second)

[llyons]

Hi Jinhuafei, I am not sure what additional information you might need.

Our CI build process pulls down the code, performs an MSBUILD on the solution file which spawns a version of VBCSCompiler. 10 minutes later when the next build runs and does a github pull or clone of the repo on top of the same folder structure, it fails to complete because files are locked and we get this..

Unable to delete file: E:\bamboo-agent-home\xml-data\build-dir\INTB-RSA-JOB1\API\packages\Microsoft.Net.Compilers.2.6.1\tools\VBCSCompiler.exe

So it does always reuse the same folder. I have watched the vbcscompiler that is in task manager and even after 10 minutes it still remains in memory. We are using 1.0.8 of Microsoft.CodeDom.Providers.DotNetCompilerPlatform and 2.6.1 of Microsoft.Net.Compilers.

what else can I provide to help better understand?

we are using the VS 2017 community edition for these builds on windows 2012r2 server

[Jinhuafei]

Thanks for the details. You can consider to use VBCSCOMPILER_TTL environment variable to reduce the TTL of VBCSCompiler.exe.

[llyons]

Hi Jinhuafei, if the default is 10 seconds and it never unloads itself, I am not sure how changing the environment variable would help. We had to use a taskkill statement in another step of the build process to get around this. This is a problem for people who build software using a build system like jenkins or bamboo or teamcity.

[Jinhuafei]

Codedom provider uses the following logic to set TTL of VBCSCompiler(code is here).

1. if there is VBCSCOMPILER_TTL environment variable and it's an integer, it will just use this value
2. if there is DEV_ENVIRONMENT or IN_DEBUG_MODE environment variable, then it will set the TTL to 15 mins
3. else uses default value 10 secs

There is probably DEV_ENVIRONMENT or IN_DEBUG_MODE defined on your build server, that's why I suggested you to set VBCSCOMPILER_TTL.

[davidcsguitar]

Install "Microsoft.Net.Compilers" with Manage Nuget Package

[bjorn-ali-goransson]

To me this sounds like https://github.com/dotnet/corefx/issues/26187 https://github.com/projectkudu/kudu/issues/2569

[PilotBob]

I am also seeing this problem with VS 2017 15.8.0. It seems to rear it's head when I switch Git branches and try to compile the new branch. Perhaps switching branches should force close the VBCSCompiler.exe process or something.

I'm not sure if switching branches is the only time I see it.

Using .Net 4.7 full, with Asp.Net. Not using core.

[Jinhuafei]

@PilotBob have you tried the latest version of Microsoft.CodeDom.Providers.DotNetCompilerPlatform? If you still see the issue with the latest version, you can file an issue here

[PilotBob]

@Jinhuafei how do I do that. Doesn't the latest version of VS 2017 use the latest version of the compilers?

[Jinhuafei]

Open Nuget package manager and check if Microsoft.CodeDom.Providers.DotNetCompilerPlatform is latest. Microsoft.CodeDom.Providers.DotNetCompilerPlatform package enables you to use new language features in asp.net views. It uses Roslyn to compile the generated code. When you build the project in VS, the cs/vb files are compiled by the Roslyn compiler shipped with VS(this part has nothing to do with Microsoft.CodeDom.Providers.DotNetCompilerPlatform)

Regarding the release, Microsoft.CodeDom.Providers.DotNetCompilerPlatform is released through Nuget, it's not tied with VS update release.