Back to Questions
1.3k
views6
comments
warning MSB3061: Unable to delete file ...
websharpertemplates ui.next

Since about mid-August, I've been getting build problems in Visual Studio 2015. For example, if I do a Clean Solution, I get several of these:

1

warning MSB3061: Unable to delete file "C:\Source\Repos\WebCad\Core\bin\Debug\Core.dll". Access to the path 'C:\Source\Repos\WebCad\Core\bin\Debug\Core.dll' is denied.

They also happen when I build. They don't happen with every build, but they happen many times a day, and the only solution is to restart Visual Studio.

If I attempt to delete these DLLs in Windows Explorer, it says:

1

The action can't be completed because the file is open in devenv.exe

I get the locked message with 6 DLLs. It's always the same 6 DLLs. 5 of them happen to be WebSharper projects, but one is not. I also have other WebSharper projects whose DLLs are not getting locked.

It so happens that the 6 DLLs concerned are all the project references from my 'Website' project (but not Website.dll itself), which is a WebSharper website using OWIN and UI.Next. I tried adding a 7th project reference to an unnecessary project, and sure enough that DLL now also gets locked.

The problem started mid-August, and this was about the time that I started using the new type provider templates. I'm wondering if they might have something to do with this.

I've also noticed that when a new version of WebSharper is available, Paket shows an error trying to replace WebSharper, and I have to restart Visual Studio and try again. I wonder if this is related?

Not sure how to reproduce the problem on demand.

.

I can now reproduce the problem with a new solution and only two projects.

See Issue #52.

By on 10/21/2015 1:44 AM ()

Issue #52 was just closed. Marking as answered.

By on 10/21/2015 4:55 AM ()

It seems to be something to do with WebSharper.UI.Next.Templating.

I can create a locked DLL situation among three of my projects. Maybe it can be even simpler, but for now this illustrates the problem. I've not tried isolating the situation to a separate solution yet.

Project dependencies:

  • Graphics uses:

    • Communication

    • Core

  • Communication uses:

    • Core

  • Core project has no project references.

Package dependencies:

  • Graphics uses:

    • WebSharper
    • WebSharper.GlMatrix

    • WebSharper.UI.Next

  • Communication uses:

    • WebSharper
    • FSharpx.Extras
    • Newtonsoft.Json

    • EnterpriseLibrary.SemanticLogging

  • Core uses:

    • FSharpx.Extras
    • EnterpriseLibrary.SemanticLogging.EventSourceAnalyzer

Here is how I create the locked DLL:

  1. Clean the solution, and close all document tabs.
  2. Build just the Core project.
  3. Open any source file from the Graphics project.
  4. Restart Visual Studio 2015.
  5. Wait for 30 seconds.
  6. Clean the solution - Core.dll is locked.

The Output window shows:

1

warning MSB3061: Unable to delete file "C:\Source\Repos\WebCad\Core\bin\Debug\Core.dll". Access to the path 'C:\Source\Repos\WebCad\Core\bin\Debug\Core.dll' is denied.

If at Step 2 I build the Communication project instead, the Core project will get built too (since it is referenced), and then at Step 6, I find both DLLs are locked.

If I miss out Step 3, the problem does not occur. It's as if IntelliSense (or something else that works on open tabs) has decided to do some work, and this locks the DLL. Note that the Graphics project is not built, but one of its source files is open.

I've tried disabling Visual Studio extensions (e.g. I'm using CommentsPlus and Visual F# Power Tools), but the problem still occurs.

Now for the interesting bit.

As shown, Graphics uses WebSharper.UI.Next. I'm using Paket, and this adds package references to both WebSharper.UI.Next and WebSharper.UI.Next.Templating. If I now manually remove the reference to WebSharper.UI.Next.Templating, and restart Visual Studio, the problem no longer occurs!

Any idea what the problem might be? This is causing me great frustration, because I keep having to restart Visual Studio, about 20 times a day currently.

By on 10/20/2015 12:03 PM ()

I have experienced the same for a few months, first with VS2013 and now with VS2015. I found that while you can't delete the assembly file, you can rename it without closing Visual Studio; so I set this pre-build action in the referenced projects:

1
2

if exist "$(OutDir)$(TargetName).old.dll" del "$(OutDir)$(TargetName).old.dll"
if exist "$(OutDir)$(TargetFileName)" ren "$(OutDir)$(TargetFileName)" "$(TargetName).old.dll"

which mostly solves the problem. Still, sometimes Visual Studio doesn't run the action before building the project and I have to do it manually.

By on 9/17/2015 9:15 PM ()

Got fed up with this, so tried your workaround, and various similar pre-build workarounds I found on the web, but it doesn't work for me. The 'old' file remains locked, so the attempt to delete it gives "Access is denied". Windows Explorer says that both the 'dll' and the 'old' file are locked by devenv.

By on 9/23/2015 11:30 AM ()

Thanks. I've seen this workaround posted a few times while I was Googling.

There are many reasons why files can get locked, the most common of which is that your program didn't shut down and is still running in the background. In this case, given the information I posted, it seems like WebSharper might be causing the problem. If so, then fixing the problem is better than employing a workaround.

By on 9/18/2015 1:24 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper