Roslyn: Design-time builds should not lock tasks coming from packages

[ghost]

Steps to Reproduce:

1. Open a project in VS2015 which has dependency on Microsoft.Bcl.Build.Tasks.dll.
2. Build the project and keep the project opened.
3. While the project is still opened in VS after the build, open cmd and cd into the solution directory and run rmdir /s/q packages (or PowerShell's rm -r -fo packages).
   
   
   
   • Alternatively, if the project is under git SC, run git clean -xdf command in cmd/ps, everything which is not under source control gets deleted, except for Microsoft.Bcl.Build.Tasks.dll.
   
   

Expected Behavior:
packages folder gets deleted. VS should release the handle to resource in user space, when there is no user-driven operation going on.

Actual Behavior:
packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.Tasks.dll - Access is denied.
VS2015 does not release handle to this particular file unless we close the solution and kill devenv and wait for like 20 extra seconds before user gets a chance to remove the packages folder.

[bkoelman]

I've seen such locks also in the past. Not with this specific assembly, but others in the packages folder. Even after VS closes or has crashed. I guess the hanging lock is caused by the out-of-process compiler server.

[ghost]

Agree there are others as well. That's why I keep one instance of PowerShell running to execute kill -name devenv; kill -name msbuild; git clean -xdf; ./SolutionName.sln every now and then. devenv and msbuild are two processes usually holding the assembly handles. In my experience, for 95+% of cases it is Microsoft.Bcl.Build.Tasks.dll in use.

[jaredpar]

Is there a reason that you think Roslyn is responsible for holding this reference? As opposed to say Visual Studio / MSBuild in general?

Have you run handle.exe when this occurs to track down which process has the handle open?

[gafter]

@jaredpar I defer to your judgment regarding which team should do the initial investigation.

[gafter]

@jaredpar I don't think we should expect the OP to diagnose the cause of this failure. Please route this to the appropriate team or close with an appropriate reason. If you're waiting for the OP (@jasonwilliams200OK) to provide more information so it can be evaluated, please let him know what that information is.

[jaredpar]

@gafter not asking to diagnose the problem. I'm asking if there is a reason they felt it was Roslyn vs. VS / MSBuild. The answer could be as simple as "no reason".

The request for running handle.exe though is real. This doesn't repro for any of us right now hence it's basically unactionable. The handle.exe output would at least help point us to the culprit so we could begin theorizing why this would happen.

[ghost]

I'm asking if there is a reason they felt it was Roslyn vs. VS / MSBuild.

When I open any solution with csprojs on PC running VS2015 and compile the project then try deleting the packages folder from command line or file explorer (without closing VS), I get access denied error.

But if I just open the solution, restore packages using package manager (UI or console) and delete the packages dir before compiling the project, it get deleted.

The difference is; if you engage the compilation step, only then the handle gets locked. It could be compiler, msbuild or VS holding the handle.

The handle.exe output would at least help point us to the culprit so we could begin theorizing why this would happen.

I downloaded handle.exe from technet and verified with MVC5 test application (the one with csproj, not MVC6 / xproj) that devenv.exe has the handle.

[pranavkumar001]

I also faced the same issue with Microsoft.Bcl.Build.Tasks.dll , i closed the VS 2015 and then it released the handle.

[davkean]

This file will be locked due to MSBuild design-time builds. Unlike "real" builds which run-out-proc, these run in-proc inside devenv. This is by the very nature of how this works - there's a couple of ways we could make changes here, including running this out-of-proc or by shadow copying tasks, but neither are a simple undertaking.

Either way, I'll move this to Project System area, and mark this as a feature request.

[davkean]

Turns out CPS, and hence the new project system already does out-of-proc builds. It sounds like the work here is to just verify that this scenario no longer repros.

[ghost]

@davkean, thanks! Would this fix be backported to VS14 (VS2015) at some point? Or should I verify against VS15 preview?

btw, what's CPS? which one from this list: http://acronyms.thefreedictionary.com/CPS? :smile_cat:

[davkean]

This won't be backported to VS14. CPS is the "Common Project System", the base infrastructure that we're building the new project system on.

The new project system hasn't been turned on in VS15 yet - so there's nothing to verify yet - here's our roadmap of when it will be enabled: https://github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md

[paul1956]

How do I add a feature request to new project system? There needs to be a way to find and replace all linked files with physical files and then reverse it. Sometimes I want to share a project via Zip or the cloud and when the receiver opens it today all the linked files are missing I am looking for an easy solution other then to stop using linked files.

[davkean]

Just file a bug on this repro.

[ghost]

@davkean, thanks for the explanation. Looking at the wiki and readme of project system, a lot is changing.

Can you please shed light on xporj, csproj and vbproj, whether we will are going to get rid off of .*proj and .sln pattern in new Project System, in favor of global.json and project.json?

In my understanding so far, xproj is only there for transition time which currently 90+% of the project related matter are moved to JSON driven configs and since MSBuild only understands XML based project file we need xproj with mere bootstraping. With CPS, there wont be a need of MSBuild so xproj/vbproj/csproj will be replaced by project.json and sln (with its weird archaic syntax) will be replaced by global.json.

Is this correct?

[davkean]

@jasonwilliams200OK Not sure if you saw, but as part of the tooling changes for .NETCore, we're merging the xproj and csproj concepts into single project system. We're looking at taking the concepts that project.json provides (*.cs support, dual build, simple editing), and moving them to MSBuild concepts so that the existing ecosystem built on MSBuild benefits from them. Changing the solution is out of scope for this project, however, we are thinking about making it easier to share settings across project, a la global.json.

[davkean]

This issue was moved to dotnet/roslyn-project-system#91

[JoseFMP]

Same problem here. Horrible bug. Can confirm still happening in VS 2017.

[davkean]

@Jose-CF See this comment: https://github.com/dotnet/project-system/issues/91#issuecomment-288287379. Basically, we have fixed this in the new project system, the legacy project system (which still drives most project types right now) still suffers from this problem.