Closed stevenvolckaert closed 2 years ago
Hello, is anyone listening? Thank you!
@stevenvolckaert We use a very similar approach - although we don't use a script, just the flag in the deploy step to remove any files not matched in the zip file. RemoveAdditionalFilesFlag
The other thing is we stop the site first, then the pool, then deploy.
I am not aware of ever having an issue with this setup.
I don't believe csc.exe or vbc.exe would be running if the application pool is stopped, but technically the VBCSCompiler.exe process could hang around.
I think you should try logging with Get-Process | Where-Object ProcessName -eq 'VBCSCompiler' | Write-Output
in your PowerShell script to see if you ever get a result.
You could simplify this to Get-Process 'VBCSCompiler' | Write-Output
and kill with
Get-Process 'VBCSCompiler' | Stop-Process
Hi @CZEMacLeod! Thanks for your suggestions, I'll try them out.
Unfortunately, we don't have a lot of control over the VBCSCompiler process. In an msbuild environment, we have a target to try and kill it before trying to re-copy the roslyn files to the output directory. But at runtime or in a release pipeline that approach doesn't work. You could always experiment with changing the TTL of the roslyn compiler server. There are instructions on the main page of this repo. (Look for "VBCSCOMPILER_TTL" or "CompilerServerTimeToLive"). Hopefully following a careful shutdown of application pools and a cleanup of any leftover VBCSCompiler processes along the lines of @CZEMacLeod's suggestions can unblock you here. Let us know if you're still having issues.
Thank you all for your suggestions.
We haven't encountered this issue any more in the last three months. I'm hereby closing this issue.
Hello!
We're using Microsoft.CodeDom.Providers.DotNetCompilerPlatform v3.6.0 in a number of our ASP.NET Web Forms and ASP.NET MVC 5 applications, and it works well.
We deploy these applications with Azure DevOps Pipelines, and just before it deploys, the pipeline stops the IIS application pool, deletes all items in the IIS website's physical path, and finally deploys the new version. This ensures nothing of the old version stays behind in the physical path; we call this a clean deploy.
The clean is done with a PowerShell script; you can see its implementation on the bottom of this post.
We notice that sometimes, the clean step fails and some files stay behind; the
Remove-Item
cmdlet throws an error Access to the path 'Microsoft.CodeAnalysis.CSharp.dll' is denied:What could be the cause of this? As I mentioned, the pipeline stops the application pool before the clean script runs, so I guess there must be another process running on the server that locked
Microsoft.CodeAnalysis.CSharp.dll
(and possibly other DLLs, too).I guess my issue is related to issue #10, in which @Jinhuafei mentions that
VBCSCompiler.exe
is using the files and hence has locked the DLLs.I've been searching the server with the
Get-Process
cmdlet for a process that looks likeVBCSCompiler.exe
(see screenshot below), but no luck.I'd like to add a PowerShell script to the pipeline, that checks whether
VBCSCompiler.exe
orcsc.exe
is running, and kill their processes before cleaning the directory.The goal ultimately, is that the clean step doesn't fail on these locked files any more.
Any ideas how I can achieve this?
Many thanks in advance for your help!
Implementation of the Remove-ItemsInPath.ps1 script: