Bug 60164 - Unable to copy or delete bin\MyAssembly.dll because it is being used by another process.
Summary: Unable to copy or delete bin\MyAssembly.dll because it is being used by anoth...
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: 15.5
Assignee: dean.ellis
Depends on:
Reported: 2017-10-12 21:41 UTC by Jim Horvath
Modified: 2017-11-01 02:30 UTC (History)
5 users (show)

Is this bug a regression?: Yes
Last known good build: 4.6.0

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Jim Horvath 2017-10-12 21:41:06 UTC
Since installing Visual Studio 2017 version 15.4 I have experienced this problem consistently.  It seems very similar to this one from June 2017:


After opening Visual Studio, I can build roughly once.  After the first build, if the problem assembly needs to be rebuilt then running a build or clean fails with various errors indicating one of the project DLLs is being held open.  Closing/re-opening Visual Studio resolves the problem until the next time

Using Process Explorer, I see that the DLL is held open by 2 MSBuild.exe processes.

My solution is for a Xamarin Forms app created using the Visual Studio template.  The "Core" assembly is the one being held open.  It also varies from the template in that all the shared libraries are .Net Standard 2.0 instead of PCLs.
Comment 1 Jim Horvath 2017-10-20 12:59:56 UTC
Is this no longer the place to post bugs?
Comment 2 Jose Gallardo 2017-10-25 17:41:05 UTC
Sorry for the delay, moving the bug to the Android team as it seems like one of their tasks is keeping the file locked.
Comment 3 dean.ellis 2017-10-27 09:33:33 UTC
@Jose do you have any further information on this issue? I have been unable to replicate so far.
Comment 4 Jim Horvath 2017-10-27 13:59:36 UTC
Some new info:

- I had temporarily removed the Android project from the solution when this was occurring.  iOS was the only target involved.

- One of the projects in the solution was using Fody.PropertyChanged (https://www.nuget.org/packages/PropertyChanged.Fody/), which tweaks the output assembly.  Fody was not running on the assembly that was being held open.  Regardless, I decided to drop Fody to get back to a  more "stock" situation, and I haven't encountered this problem since.
Comment 5 dean.ellis 2017-10-30 10:28:26 UTC
Hi Jim

Thanks for the info, it sounds like PropertyChanged.Fody might have been the issue. However I have looked at the code in that project and I can't see where it hooks into the build process. There are no .target files or msbuild. 
Is it something the user has to hook up manually?
Comment 6 Jim Horvath 2017-10-30 12:46:38 UTC
No, the user doesn't have to hook anything manually.  PropertyChanged.Fody depends on Fody, which is probably where the build process hooking occurs.

github:  https://github.com/Fody/Fody
nuget:  https://www.nuget.org/packages/Fody/
Comment 7 dean.ellis 2017-10-30 14:25:59 UTC
The VS team and going to reach out of the Fody package maintainer and see what they can do to fix this.
Comment 8 Joaquin Jares 2017-10-30 14:51:09 UTC
I added an issue in Fody: https://github.com/Fody/Fody/issues/420. We've seen that before on our side, and this looks like it's exactly the same.
Comment 9 Joaquin Jares 2017-11-01 02:30:33 UTC
New update: Fody 2.2 resolves this issue, but if you don't explicitly install Fody the PropertyChanged nuget installs a 2.1. The super simple workaround is to install Fody 2.2 manually, and the issue goes away while still not having to write every single Property boilerplate :)