Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
Is this no longer the place to post bugs?
Sorry for the delay, moving the bug to the Android team as it seems like one of their tasks is keeping the file locked.
@Jose do you have any further information on this issue? I have been unable to replicate so far.
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.
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?
No, the user doesn't have to hook anything manually. PropertyChanged.Fody depends on Fody, which is probably where the build process hooking occurs.
The VS team and going to reach out of the Fody package maintainer and see what they can do to fix this.
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.
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 :)