The solution I am currently working on, the team made the decision to use habitats way of publishing projects in our solutions via gulp tasks. We are finding out however that periodically when we try to publish to our web-root the files are locked and the whole publish process fails because of this.

This causes two problems:-

  • Unclean half publishes
  • Time wasted, waiting to deploy again

So I want to know a few things:-

  • Is there a way to avoid the half publishes or a way to reverse what we have tried to publish?
  • Can we get round this intermittent issue of files being locked by a process?
  • Is this a fix we can do modifying our gulp scripts if not then any other guidance is appreciated.

Example lock

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Deploy\Microsoft.Web.Publishing.Deploy.FileSystem.targets(96,5): 
error : Copying file obj\Debug\Package\PackageTmp\bin\roslyn\csc.exe to C:\inetpub\wwwroot\WebSite.local\Website\bin\roslyn\csc.exe failed. 
The process cannot access the file 'C:\inetpub\wwwroot\WebSite.local\Website\bin\roslyn\csc.exe' because it is being used by another process. Error!
  • Do you know which files are causing the issue/lock? Normally, run-time files would not be part of a solution setup and therefore publishing of it.
    – Mark Cassidy
    Oct 20, 2016 at 23:56
  • @MarkCassidy it is normally, caused by dependencies binaries, such as application insight binaries in my last failed publish.
    – Anicho
    Oct 21, 2016 at 0:01
  • Have you considered packaging up the site files into a zip and then transferring to the server? Then you can stop deploy and restart the web application. Oct 21, 2016 at 0:07

3 Answers 3


As asked in comments above; normally /bin files should not be locked for any particular reason (other than when the site is just starting up) - so I'm not entirely sure what's going on.

I can help you on the intermittent part of your question however; I would just flip the app pool before starting the file publish task.

appcmd recycle apppool /apppool.name

There are a few NPM modules that can execute this for you. One would be gulp-run. It would look something like this:

gulp.task('reset-apppool', function() {
  return run('appcmd recycle apppool /apppool.name').exec()

EDIT: Updated to include after additional information was added to original question

The fact that Roslyn is the locked file, this may actually lead to more of an answer. I suspect Roslyn.exe is busy compiling all of the SPEAK views in your solution (or even just your own .cshtml files) and that is why it is locked at the time you deploy again.

I sourced some information from this answer: https://stackoverflow.com/a/38309167/81631

And I assume you have the DotNetCompilerPlatform package referenced in your project?

If this is all true, there are two things I would try next.

  1. Follow the recommendation in the answer - even if I am not entirely sure of the full ramifications of it.

To resolve this issue, simply uncheck the "Allow precompiled site to be updatable" option in your publish profile settings. This should pre-compile your views and allow your C# 6.0 (Latest version of Roslyn Compiler) to run like a champ.

  1. If this doesn't help; possibly your site is spending too much time on recompiling over and over. I recommend adding the optimizeCompilations attribute to your web.config <compilation> element.
<compilation debug="true" optimizeCompilations="true">

See if that makes the problem go away.

  • I am giving this a whirl. Will feedback results, mid-day tomorrow, see if the team moans about process locks.
    – Anicho
    Oct 21, 2016 at 0:16
  • optimizeCompilations="true" seems to have done the trick
    – Anicho
    Oct 21, 2016 at 0:38
  • Just to make clear, few of the other devs still experienced issues even with optimizeCompilations but with that and the additional gulp task, we've had 0 problems.
    – Anicho
    Oct 21, 2016 at 15:40
  • Same here my problem started when i added 1 more feature project to the helix based solution :(. tried the compilation in the web config, and only things that seems to work partly is to actually stop IIS rebuild then restart again. Apr 19, 2018 at 2:25

I used Habitat build chain some time ago and had similar issues. I am not sure if it solve 100% of our problems but here is what I learned.

Locked items

Check your references. Exclude unnecessary DLLs from publishing.

Unnecessary dlls are those dlls which are present in Sitecore Website/bin directory by default. You should avoid copying Sitecore.Kernel.dll, Sitecore.Client.dll and so on.


  • Find potentially broken projects
  • Identify unnecessary referenced dll in your project
  • Right click on it and select Properties
  • Set Copy Local property to False

I remember that those unnecessary referenced caused some issues while running Publish Projects .

Unclean half publishes:

One of the reason why your files might be still unpublished even if you run publish and everything seems to be fine is Local.pubxml.user file.

Navigate to your project folder: c:\proj\src\Foundation\P1\code\Properties\PublishProfiles\. and remove it (there are two files Local.pubxml, Local.pubxml.user - first one is fine, second is a temporary file.)

Hope it solve at least one of your problems.

  • I think this is a long term solution, as the clean up task debt of the projects and their references, which has built up quickly over time. Will ensure we tidy up what we can going forward.
    – Anicho
    Oct 21, 2016 at 0:17
  • 2
    Bear in mind that if you set Copy Local=false that you will lose IntelliSense in your Razor Views. It would be better to use Publish Profile settings: jammykam.wordpress.com/2016/01/20/…
    – jammykam
    Oct 21, 2016 at 10:58

Sitecore Habitat Hanging on 05-Sync-Unicorn

Make sure to unblock following files in the code repository, you can do so by right click on each one of them and click on Unblock:

  • Habitat-master\scripts\Unicorn\MicroCHAP.dll
  • Habitat-master\scripts\Unicorn\Sync.ps1
  • Habitat-master\scripts\Unicorn\Unicorn.psm1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.