projbook creates a lock on msbuild.exe on tfs build agents

[robinbihun]

i'm trying to find out how to get more details for you since i dont have full access to our build environment; however, it appears that projbook projects in the solution build successfully but never release and even after the build is completed in TFS (successful or failure) msbuild.exe is "stuck" running. This causes the next build under that build configuration to fail as it cannot reset the build directory.

Steps to reproduce:

1. Create a solution which has a projbook project.
2. Create a build configuration in TFS2015 that builds the solution
3. Checkin your solution and build using that configuration (should be successful)
4. Trigger a new build using that same configuration, build should fail due to an "access is denied" error on some file in the directory.
5. Restart the build agent (or kill the msbuild process).
6. Remove the projbook project from your solution
7. Check-in the changes and trigger a new build using the same configuration (should be successful again)
8. Trigger a new build using that same configuration, this time it will be successful.

Using the latest version of projbook (1.0.6) and .NET 4.6.1 on VS2015 Enterprise edition and TFS (on prem) 2015 update 3.

[defrancea]

Hey Rob!

I'm very interested to know which file is getting an access denied, any clue on that? When getting this access denied, is it failing during the Projbook execution or before during the nuget execution?
MSBuild keeps by default background process in order to speed up future builds and support parallel build so this part is expected: http://stackoverflow.com/questions/12174877/visual-studio-2012-rtm-has-msbuild-exe-in-memory-after-close
However, when building your documentation project, MSBuild will load the Projbook dll target and will then keeps a lock on the file (packages/Projbook.x.x.x/tools/Projbook.Target.dll) and thus any future build operation removing this file would get an access denied and fail.

In order to troubleshoot this issue I recommend to:

• Determine the file that is getting an access denied (if possible)
• Determine if the access denied happens during the Projbook execution or before (if possible)
• Ensure there is no build operation wiping nuget dependencies, if yes, you need to
  • Either skip the packages cleanup for projbook
  • Or disable the node reuse mode of MSBuild

I'm changing the issue type to Bug until we figure out what's going here.

[robinbihun]

I'm trying to get more details on this... the file that was blocked was not one in the projbook project, but one of the other projects it referenced. Removing the projbook project from my solution and rebuilding (after getting someone to restart the tfs server's msbuild process) and it was successful.

Access to the path 'd:\agt\138\s\packages\Microsoft.Net.Compilers.1.3.2\tools\Microsoft.Build.Tasks.CodeAnalysis.dll' is denied.
Prepare repository failed with exception. 

[defrancea]

Interesting ... so this is Roslyn used by the C# extractor in order to parse the C# AST and index syntax nodes for pattern patching during specific member extraction.
One dll is already provided within the tool directory of the nuget package, but for some reason your MSBuild is reusing this one that is probably already loaded coming from another dependency.
Projbook 1.1 uses a plugin system for extractors using MEF that changes the way these dlls are loaded.
In order to resolve your issue, it really worth trying to update Projbook to this prerelease: https://www.nuget.org/packages/Projbook/1.1.0-cr2 (It's a non-breaking very close to be released version. It's used in production in my company).
You might also want to look at why the build is re-downloading the dependency even when they are already there but it's not the problem we're trying to resolve unless it tries to wipe Projbook as well later on.
I tried to do some basic repro with Projbook 1.1 but I couldn't find anything.
Let me know if you find anything, I can try further troubleshooting on 1.0 if necessary.

[robinbihun]

I will try 1.1.0-cr2 this afternoon.

It gives us the file lock error during the first step when git is pulling the latest code (nothing in the packages folder is actually versioned).

[defrancea]

Hello @robbihun, I haven't not followed up since a while because assumed that your problem was resolved but I would like to confirm this before closing this issue.

[robinbihun]

I have not been able to confirm - we have changed our build process to work around this particular issue.

Thanks for following up!