Unable to copy roslyn files due to file lock from VBCSCompiler.exe

[DerDreschner]

Even we are on version 2.0.0, we experience some issues with locks from the VBCSCompiler.exe (see logs).

18>Unable to add 'bin/roslyn/Microsoft.CodeAnalysis.dll' to the Web site.  Unable to add file 'bin/roslyn/Microsoft.CodeAnalysis.dll'.  The process cannot access the file because it is being used by another process.
18>Unable to add 'bin/roslyn/Microsoft.CodeAnalysis.VisualBasic.dll' to the Web site.  Unable to add file 'bin/roslyn/Microsoft.CodeAnalysis.VisualBasic.dll'.  The process cannot access the file because it is being used by another process.
18>Unable to add 'bin/roslyn/Microsoft.DiaSymReader.Native.amd64.dll' to the Web site.  Unable to add file 'bin/roslyn/Microsoft.DiaSymReader.Native.amd64.dll'.  The process cannot access the file because it is being used by another process.
18>Unable to add 'bin/roslyn/System.Collections.Immutable.dll' to the Web site.  Unable to add file 'bin/roslyn/System.Collections.Immutable.dll'.  The process cannot access the file because it is being used by another process.
18>Unable to add 'bin/roslyn/System.IO.Compression.dll' to the Web site.  Unable to add file 'bin/roslyn/System.IO.Compression.dll'.  The process cannot access the file because it is being used by another process.
18>Unable to add 'bin/roslyn/System.IO.FileSystem.dll' to the Web site.  Unable to add file 'bin/roslyn/System.IO.FileSystem.dll'.  The process cannot access the file because it is being used by another process.
18>Unable to add 'bin/roslyn/System.IO.FileSystem.Primitives.dll' to the Web site.  Unable to add file 'bin/roslyn/System.IO.FileSystem.Primitives.dll'.  The process cannot access the file because it is being used by another process.
18>Unable to add 'bin/roslyn/System.Reflection.Metadata.dll' to the Web site.  Unable to add file 'bin/roslyn/System.Reflection.Metadata.dll'.  The process cannot access the file because it is being used by another process.
18>Unable to add 'bin/roslyn/System.Security.Cryptography.Primitives.dll' to the Web site.  Unable to add file 'bin/roslyn/System.Security.Cryptography.Primitives.dll'.  The process cannot access the file because it is being used by another process.
18>Unable to add 'bin/roslyn/System.ValueTuple.dll' to the Web site.  Unable to add file 'bin/roslyn/System.ValueTuple.dll'.  The process cannot access the file because it is being used by another process.
18>Unable to add 'bin/roslyn/VBCSCompiler.exe' to the Web site.  Unable to add file 'bin/roslyn/VBCSCompiler.exe'.  The process cannot access the file because it is being used by another process.

We're unsure what we could do to assist you to analyse the issue..?

[Jinhuafei]

Is this a web site project?

[DerDreschner]

Yes, it happens on a web site project.

[DerDreschner]

Happend again, but this time, even visual studio crashed. But I'm not sure if it does mean anything, as vs sometimes crashes at the end of the publishing.

[DerDreschner]

And here are the lock handles from process explorer as the problem occurs

[Jinhuafei]

VBCSCompiler.exe is the Roslyn compiler service process which is used to do asp.net runtime compilation. You can kill this process before publishing, or use CheckIfShouldKillVBCSCompiler in [sitename].publishproj.

[DerDreschner]

Ahh, so, it is necessary to include CheckIfShouldKillVBCSCompiler in the MSBuild pipeline? I thought that it would be done automatically by RoslynCodeDomProvider at buildtime or before/while publishing! Will try that then.

[DerDreschner]

Hmm, but I'm a little bit unsure if it shouldn't work anyway. We have the publish settings in our csproj file, and in there, we have

<Import Project="..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />

right at the top of the file as it was included by the NuGet installation anyway. Aditionally, we have

<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.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
</Target>

at the end, so, it should get an error when it doesn't see the props file. All web projects are MVC.NET with framework 4.6.1. The projects are under C:\Dev\Project, while the web deploy targets to C:\inetpub\wwwroot\dev-standalone\Website.

So, am I wrong? Is there any possibility to check if he tries to kill the VBCSCompiler.exe processes?

[DerDreschner]

Ahh, I see what you mean!

In CheckIfShouldKillVBCSCompiler, you check if the VBCSCompiler in $(RoslynToolsDestinationFolder) will be overwriten. As $(RoslynToolsDestinationFolder) is C:\Dev\Project\Source\Web\bin\roslyn\ it will check against our build folder, where File.Exists(Src) && File.Exists(Dest) && (File.GetLastWriteTime(Src) != File.GetLastWriteTime(Dest)) will only be true if we update the RoslynCodeDomProvider. So, only when we would update the NuGet package, the VBCSCompiler.exe would be killed.

But because we use web deploy, it should always be killed in our development environment. I did that now with the following lines in our *.csproj (we don't have a *.publishproj in our solution; should we have one in our web projects with ASP.NET MVC 5?):

<Target Name="CheckIfShouldKillVBCSCompiler">
  <PropertyGroup>
    <ShouldKillVBCSCompiler>true</ShouldKillVBCSCompiler>
  </PropertyGroup>
</Target>

which works fine for us.

Thank you very much for your support; you can close the ticket now. I'll leave it open, as I'm not sure if you're able to answer my question reguarding the *.publishproj file if I'll do it.

[Jinhuafei]

If there is csproj file under your web app folder, then this is a web application project(not web site project). For web application project, you don't need *.publishproj file, because the publishing task can be put into the csproj.
I wasn't able to repro the issue. Can you provide publish msbuild log? Maybe I can make some change to fix the problem.

[DerDreschner]

Ahh, yeah, sorry for the confussion by my little mistake!

I've reproduced it once more and add you a build log from visual studio. As I don't want to show the customers name, I've replaced all "dangerous" informations with Amstrad. Hope that it's still readable. And to avoid any more confussion: The web deploy target is www.dev-am.de as in the first screenshots, but that points to a local IIS instance with 127.0.0.1 which is under C:\inetpub\wwwroot\dev-standalone\Website.

buildlog-vbcscompiler-problem.txt

[Jinhuafei]

Thanks for the log file. I'll take a look and see what I can do.

[DerDreschner]

Thank you very much!

Just to keep you informed: With this workaround, we sometimes have the issue that we get a "Reference not set to an object" error while building. As source, visual studio shows the Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props. Don't know the line number at the moment, I think it was one of the kill targets. I try to reproduce it and provide you an msbuild log including this error.

[DerDreschner]

Had the described error message right now. Here is a screenshot of the error and the msbuild log. Hope that you have a better solution in the long term. And sorry for the zip file, but the log is too big for uploading them as single txt (~30MB) as I were building the whole solution at that time.

msbuild-object-error.zip

EDIT: Sorry, I saw that this error is fixed by #54. So, nevermind. :)

[DerDreschner]

I have problems at the moment even with my workaround. I'm a little bit confused what does fail here...? I had to kill VBCSCompiler.exe by hand. Even stopping the IIS app pool didn't helped.

Here is the log:
msbuild-with-workaround.txt

[Jinhuafei]

As I mentioned in issue #58, the VBCSCompiler.exe process is started by asp.net to do the runtime compilation on the web server which fails the publish because of the file lock. The workaround is only for the lock issue at build time on your dev box or CI box. If fully pre-compiling the views is not an option for you, you may consider to specify the TTL of Roslyn compiler server(you can find more info here) to have VBCSCompiler process auto shutdown sooner.

[edika99]

same here only for bin/roslyn/Microsoft.CodeAnalysis.VisualBasic.dll on Visual Studio 2017 on webform project in c#