This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 56275 - Unable to copy appname.dll from obj to bin because it is being used by another process
Summary: Unable to copy appname.dll from obj to bin because it is being used by anothe...
Status: CLOSED FIXED
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: General (show other bugs)
Version: 4.5.0 (15.2)
Hardware: PC Windows
: High major
Target Milestone: 15.2.2
Assignee: Bugzilla
URL:
: 56306 56800 56917 (view as bug list)
Depends on: 56587
Blocks:
  Show dependency tree
 
Reported: 2017-05-12 10:00 UTC by Michel Moorlag
Modified: 2017-06-06 22:16 UTC (History)
92 users (show)

See Also:
Tags: 15.1I
Is this bug a regression?: Yes
Last known good build: Xamarin.VisualStudio 4.4.0.34 (3f99c5a)


Attachments
Logs (48.75 KB, application/x-zip-compressed)
2017-05-24 10:11 UTC, Neha Kharbade
Details

Description Michel Moorlag 2017-05-12 10:00:25 UTC
I am using using Visual Studio 2015 update 3 and developing a Xamarin Forms application

Yesterday I installed XF for VS 4.5.0.443 and since that I am getting:

Error Unable to copy file "obj\Debug\appname.dll" to "bin\Debug\appname.dll". The process cannot access the file 'bin\Debug\appname.dll' because it is being used by another process.
 Error Could not copy "obj\Debug\appname.dll" to "bin\Debug\appname.dll". Exceeded retry count of 10. Failed.

For Android a clean solutions sometimes seems to work but I am unable to build and run any IOS project
Comment 1 Michel Moorlag 2017-05-12 10:01:43 UTC
There are more developers facing the same issue. See: https://forums.xamarin.com/discussion/32976/updating-xamarin-broke-the-build-process-the-process-cannot-access-the-file-appname-dll-mdb
Comment 2 Mirko Da Corte 2017-05-12 10:58:13 UTC
Same here, VS 2017. I've tested only with Android, and with external dependencies projects it's a realy pain. I've to build one by one, and delete related bin/obj folders every time for make it build. Currently unusable.
Comment 3 Wilco ten Voorde 2017-05-12 11:53:03 UTC
Encountering the same problems. A sloppy workaround is to restart Visual Studio every time this error occurs. This works for me at the moment.
Comment 4 Wilco ten Voorde 2017-05-12 11:53:34 UTC
Encountering the same problems. A sloppy workaround is to restart Visual Studio every time this error occurs. This works for me at the moment.
Comment 5 Brian Macomber 2017-05-12 14:12:34 UTC
I'm also seeing the same issue with Xamarin Forms on UWP, iOS and Android.  It always seems to be the shared PCL library.  VS 2017 17.2, just started happening after I updated VS the last time.
Comment 6 Brian Macomber 2017-05-12 14:13:48 UTC
Forgot a quicker work around than restarting VS, open the output path and delete the bin dir of the file that is in use, usually works for me
Comment 8 Don Miller 2017-05-12 14:49:18 UTC
I have seen the same thing since updating VS2017 to:

Microsoft Visual Studio Enterprise 2017 
Version 15.2 (26430.4) Release
VisualStudio.15.Release/15.2.0+26430.4
Microsoft .NET Framework
Version 4.6.01586

Installed Version: Enterprise

Xamarin   4.5.0.443 (c871575)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android SDK   7.3.0.13 (448f54f)
Xamarin.Android Reference Assemblies and MSBuild support.

Xamarin.iOS and Xamarin.Mac SDK   10.10.0.30 (30b6e87)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

Here are the exact error messages.

Severity	Code	Description	Project	File	Line	Suppression State
Error		Unable to copy file "obj\Debug\CsetMFDiagram.dll" to "bin\Debug\CsetMFDiagram.dll". The process cannot access the file 'bin\Debug\CsetMFDiagram.dll' because it is being used by another process.	CsetMFDiagram		
Severity	Code	Description	Project	File	Line	Suppression State
Error		Could not copy "obj\Debug\CsetMFDiagram.dll" to "bin\Debug\CsetMFDiagram.dll". Exceeded retry count of 10. Failed.	CsetMFDiagram			

I'm using Xamarin.Forms v2.3.4.231

It happens on both Android and iOS.
Comment 9 Joshua Poling 2017-05-12 17:44:28 UTC
I have the same problem after updating VS2017 -> 15.2 (26430.4). I can't even get the iOS project to build even if I delete all previous build files.
Comment 10 Joshua Poling 2017-05-12 18:57:41 UTC
Issue still exists on VS 2017 update 15.2 26430.06
Comment 11 Brian Macomber 2017-05-12 20:45:13 UTC
After some more testing I've found that my UWP and iOS project build, after manually deleting the bin folders.  But I can't get my android project to finish building.  It gets access errors in its own bin folder while building
Comment 12 Brendan Zagaeski (Xamarin Support) 2017-05-12 22:26:09 UTC
*** Bug 56306 has been marked as a duplicate of this bug. ***
Comment 13 Rhussell 2017-05-12 23:41:32 UTC
Same problem. VS2017 version 15.2(26430.6).
1. kill all MsBuild.exe processes (for the dll opened by msbuild.exe);
2. or, wait for a few minutes;
3. or, restart VS (for the dll opened by devenv.exe);
These workarounds work for me but very boring.
Comment 14 DmytroBondarenko 2017-05-13 10:14:32 UTC
cmd script with del command for each problem file also works fine, in general about 100%. 
del PROJECT\bin\Debug\FILENAME.dll
I also tried to put this command into VS PreBuild event, but it didn't help me.
Comment 15 Stuart Crawshaw 2017-05-13 13:29:03 UTC
This seems to happen to me *during* the build process.

I can use Handle.exe to close the open files, Clean the solution, start to debug the Android project (on a real device) and my DLL cannot be copied as it is locked.

Its *always* the first DLL that it locks, even though no locks existed before i click Debug.

I have parallel build set to 1 and this is really killing my productivity.
Comment 16 rohan bethune 2017-05-14 15:06:05 UTC
This is a major productivity issue. Xamarin iOS/Android build is painfully slow as it is and this bug really is the icing on the cake.

Current painful w/a :

1) Killing all MSBUILD processes
2) Restarting VS 

or

1) switching from debug/release mode sometimes unlocks the locked file(s).

Using :

VS 2017 15.2 (26430.6)
Xamarin 4.5.0.443

Going back to VS 15.1 I dont have the issue.
Comment 17 Eric 2017-05-14 18:11:20 UTC
One thing I've noticed is that this problem does not seem to occur with Shared Library projects, it only occurs with PCL projects.  It's always the cross-platform library that's locked by devenv.exe too.  I'm left wondering if perhaps something is happening with the Xamarin.Forms XAML previewer in Visual Studio that's causing the file to be locked.

I've switched to a shared library solution because of this issue; the productivity drain was just too much otherwise.  It's taken a bit to refactor the dependency injection stuff into partial classes but simply being able to work and view updates quickly in the simulators was worth the hit.
Comment 18 wil 2017-05-14 19:29:47 UTC
Wow, not sure if this is visual studio issue or xamarin issue.

Please fix this ASAP.  This bug is just killing me.
Comment 19 Joshua Poling 2017-05-14 19:32:17 UTC
I'm not using xaml in my project and I still have the build issues. The only way I've been able to get past this issue is deleting the obj debug on each project after running it.
Comment 20 Michel Moorlag 2017-05-15 07:44:22 UTC
I did a test. I cleaned the solution, closed VS and killed any running build process. After that I removed the obj and bin folders and rebooted my machine. This way I am pretty sure that I don't have any locked binary files. I don't have any binaries at all. Then I started a debug session for IOS and behold the error was there. This tells me that the lock is not form a previous build but produced during the current build.
This makes me wonder if removing binaries is really useful? For me it does not seem to work for IOS at least.
Comment 21 Michel Moorlag 2017-05-15 08:27:09 UTC
I also noticed that some basic XF projects I did in the past to test some things don't have this problem. Only the more advanced solutions with tons of nugget packages seems affected in my case. Which makes me wonder if it is a combination of one or more nugget package(s) in combination with Xamarin for VS 4.5.0.443.
For example if I try to build the Xamarin evolve 2016 app from James Montemagno I now have this issue while in the past I could build his app without any problem. See: https://github.com/xamarinhq/app-evolve

No I get this:
Severity	Code	Description	Project	File	Line	Suppression State
Error		Unable to copy file "obj\Debug\XamarinEvolve.DataStore.Abstractions.dll" to "bin\Debug\XamarinEvolve.DataStore.Abstractions.dll". The process cannot access the file 'bin\Debug\XamarinEvolve.DataStore.Abstractions.dll' because it is being used by another process.	XamarinEvolve.DataStore.Abstractions			
Error		Could not copy "obj\Debug\XamarinEvolve.DataStore.Abstractions.dll" to "bin\Debug\XamarinEvolve.DataStore.Abstractions.dll". Exceeded retry count of 10. Failed.	XamarinEvolve.DataStore.Abstractions			
Error		Could not copy "obj\Debug\XamarinEvolve.Utils.dll" to "bin\Debug\XamarinEvolve.Utils.dll". Exceeded retry count of 10. Failed.	XamarinEvolve.Utils			
Error		Unable to copy file "obj\Debug\XamarinEvolve.Utils.dll" to "bin\Debug\XamarinEvolve.Utils.dll". The process cannot access the file 'bin\Debug\XamarinEvolve.Utils.dll' because it is being used by another process.	XamarinEvolve.Utils			
Error		Could not copy "obj\Debug\XamarinEvolve.Clients.Portable.dll" to "bin\Debug\XamarinEvolve.Clients.Portable.dll". Exceeded retry count of 10. Failed.	XamarinEvolve.Clients.Portable			
Error		Unable to copy file "obj\Debug\XamarinEvolve.Clients.Portable.dll" to "bin\Debug\XamarinEvolve.Clients.Portable.dll". The process cannot access the file 'bin\Debug\XamarinEvolve.Clients.Portable.dll' because it is being used by another process.	XamarinEvolve.Clients.Portable			
Error		Unable to copy file "obj\Debug\XamarinEvolve.Clients.UI.dll" to "bin\Debug\XamarinEvolve.Clients.UI.dll". The process cannot access the file 'bin\Debug\XamarinEvolve.Clients.UI.dll' because it is being used by another process.	XamarinEvolve.Clients.UI			
Error		Could not copy "obj\Debug\XamarinEvolve.Clients.UI.dll" to "bin\Debug\XamarinEvolve.Clients.UI.dll". Exceeded retry count of 10. Failed.	XamarinEvolve.Clients.UI			
Error		File not found: /Users/mhgmoorlag/Library/Caches/Xamarin/mtbs/builds/XamarinEvolve.iOS/d03f315e031209d0cc9075c2dcc4fe94/Resources/Images.xcassets/AppIcons.appiconset/Icon-58.png	XamarinEvolve.iOS
Comment 22 Jason Brown 2017-05-15 12:54:22 UTC
I've started having this problem as well - I'm using VS2015. The workaround that I'm using is to disable the build of all the PCLs in the Configuration Manager then build them explicitly as required before building the platform specific project.

It's a bit of a rubbish workaround because it's easy to get things out of sync, but it has allowed me to continue development.
Comment 23 softlion 2017-05-15 13:10:42 UTC
I have this problem since i updated to alpha/beta channel in april which is now the stable channel.
Comment 24 Mark Downes 2017-05-15 20:51:00 UTC
I have this same problem as well in Visual Studio 2015 Update 3 since updating to the May 2017 release.
Comment 25 Brian Macomber 2017-05-15 20:52:24 UTC
Another observation, I can build iOS projects for the simulator, but not for a device. XamlCTask fails because the dll is in use
Comment 26 Stuart Crawshaw 2017-05-15 21:06:22 UTC
I am almost certain that this is an issue with an Android build target.

I can get the error, use Handle.exe to clear locks and then remove all files.

My environment at this point has no \bin or \obj folders in any project.

I attempt to build the projects and get a lock error.


However, if i repeat the steps up to having  no \bin or \obj folders, but this time only build my Shared library, it works.

Build my Android library, and all is well.
Comment 27 Brendan Zagaeski (Xamarin Support) 2017-05-16 01:48:34 UTC
## Off-site cross-reference for bookkeeping

https://developercommunity.visualstudio.com/content/problem/54945/compilaion-fails-because-proces-cannot-access-dll.html
Comment 29 Vladislav Kosev 2017-05-16 08:19:30 UTC
I can confirm that that happens in both VS2015 and VS2017 after the last Xamarin update.
It is an absolute nightmare to work!
Comment 30 Michel Moorlag 2017-05-16 08:31:09 UTC
I agree. Building and debugging Xamarin never was lightning fast but now it is like doing a marathon on your hands and knees :(
Comment 31 Michel Moorlag 2017-05-16 08:34:59 UTC
I am not sure how long it will take to fix this but this is absolutely unworkable for me while I have deadlines to make. Is there somebody who know how to revert Xamarin for Vs to a previous version until this is fixed?
Comment 32 Vladislav Kosev 2017-05-16 08:43:06 UTC
I would be happy with a workaround which works every time - e.g. disable something, whatever. This deleting of files... I have a large solution, it locks 4-5 projects at a time sometimes, its awful.
Comment 33 Jason Brown 2017-05-16 08:47:48 UTC
I'm managing to work reasonably well by disabling the build of the projects I'm not working on. I just build the project I'm working on and the Droid project.

On a different topic, it's slightly concerning that the bug status is still NEW. Does anyone know if Xamarin are looking into this?
Comment 34 Vladislav Kosev 2017-05-16 08:55:49 UTC
"slightly" being an understatement.
Comment 35 softlion 2017-05-16 09:44:31 UTC
It is a new bug from this version.
Anyone using resharper ? 
Maybe it is related as it has been updated too with nearly the same timing.
Comment 36 Vladislav Kosev 2017-05-16 09:56:35 UTC
I'm not using it.
Comment 37 Michel Moorlag 2017-05-16 10:16:50 UTC
I am not using resharper either so I think we can rule that out. I am pretty sure it is the latest Xamarin for VS update.

I noticed I can change status of this bug because I created it I guess. But changing the status won't change the fact that it is not under attention of the Xamarin team. How do we bring this under their attention? 

Is there somebody from the Xamarin team that can respond to our suffering? Please!
Comment 38 rohan bethune 2017-05-16 10:40:44 UTC
Yes, i'm using Resharper and the problem exists with this extension. Even when Resharper is disabled or completely removed - the issue still exists.

Using Enterprise version of VS for both 2015 and 2017 - problem exists in both versions.

However - I appear to have found a workaround (works for me anyway)

Start VS in ADMIN mode.

I dont appear to have the problem  as bad as I did (every build required a restart of W10/Parallels)

HTH
Comment 39 Vladislav Kosev 2017-05-16 10:46:11 UTC
But you still have the problem?
Comment 40 rohan bethune 2017-05-16 10:56:03 UTC
No - as I mentioned in my last post , running VS in ADMIN mode resolves the LOCK issue for me so far - compiled 18 times. Previously every compile gave the LOCK issue.
Comment 41 Vladislav Kosev 2017-05-16 11:04:30 UTC
That's a decent workaround and it would explain a lot for the bug.
Comment 42 rohan bethune 2017-05-16 11:16:55 UTC
Yep, hopefully will help everyone until a fix is out. Only issue is ADMIn mode apparently doesnt respect (in my setup anyway) SUBSTituted folders/paths so if you have set these up to limit very long path/folder names you would need to rethink that set up.
Comment 43 Vladislav Kosev 2017-05-16 11:17:57 UTC
Thanks
Comment 44 Michel Moorlag 2017-05-16 11:35:57 UTC
I tried the admin trick before and tried it again but for me it does not make ANY difference :(
Can't build IOS and for Android I have to restart VS every two or three builds. And even restart it won't build every time.
Comment 45 rohan bethune 2017-05-16 11:42:19 UTC
thats a pity , but yeah, as mentioned - works for me in my setup .. forgot to mention that i completely cleaned caches folders (deleted MTB, XMA folders etc) on MAC (before i launched VS in ADMIN mode)  and ensured no AV software running apart from standard Defender
Comment 46 Jim Horvath 2017-05-16 14:28:06 UTC
I always run VS in admin mode and I have this problem.
Like many others posting here, I have deadlines and I feel like my commitment to Xamarin is making me look like a huge a**hole.
Comment 47 Brian Macomber 2017-05-16 14:30:19 UTC
I've found running VS in admin mode as suggested has improved things when building for iOS, but not UWP...have to delete the bin dir everytime.

Between this issue and break points not working again, it's seriously painful.  I can't figure out how to roll back to VS 2017 15.1 or I would!
Comment 48 Philipp Sumi 2017-05-16 15:56:58 UTC
+1. 15.2 is really completely broken for me.
Comment 49 Olexander Ivanitskyi 2017-05-16 16:16:05 UTC
I wrote to support and they provided a link to the older version of Xamarin for Visual Studio - 4.4:
https://dl.xamarin.com/XamarinforVisualStudio/Windows/Xamarin.VisualStudio_4.4.0.34.msi

I also downgraded Xamarin iOS on the Mac to 10.8 following this instruction:
https://kb.xamarin.com/customer/portal/articles/1699777-how-do-i-downgrade-to-an-older-version-of-xamarin-

Now it works.
Comment 50 DmytroBondarenko 2017-05-16 16:46:53 UTC
For now the solution is (to decrease global level of painful): 

1. write CMD script with next content

del prj_name\bin\Debug\outputname.dll (repeat this line for other dlls, if you have more than one)

2. use win+r with command 'tskill msbuild'

That's all!

When you see the error just run 2 than 1, but in general 1 works good.
Comment 51 Brendan Zagaeski (Xamarin Support) 2017-05-16 20:19:34 UTC
> attention of the Xamarin team
Yes, this issue is a top item for investigation by the Xamarin team.  For some small measure of additional public visibility and transparency, I have listed it as the top issue in a preliminary list of the in-progress work related to the 15.2 release on:
https://forums.xamarin.com/discussion/95110/stable-channel-and-vs-2017-15-2-feature-release/p1

I am also coordinating with the engineering team to keep them up-to-date with incoming information about the issue.


> how to roll back
The release blog post [1] includes information about available downgrade scenarios.  Note that for Visual Studio 2017 there is an unfortunate limitation as mentioned on that post that the previous available version is 15.0 to follow the Visual Studio update guidelines.

[1] https://releases.xamarin.com/stable-release-15-2/
Comment 52 Daniel Cazzulino 2017-05-16 20:58:42 UTC
Could you guys try the envvar MSBUILDDISABLENODEREUSE=1 just in case, as documented in https://github.com/Microsoft/msbuild/wiki/MSBuild-Tips-&-Tricks
Comment 53 Jason Brown 2017-05-16 21:30:57 UTC
Hi Daniel,

I'm trying that now and I've not had any failures yet - but this problem is somewhat inconsistent. I'll keep the environment variable set and let you know if I have any problems tomorrow.

I suggest that other people try this as well - hopefully it'll help us carry on working and might give you a good indication to you of where the problem lies.

Thanks for the suggestion

Cheers

Jason
Comment 54 Daniel Cazzulino 2017-05-16 21:34:20 UTC
Glad to hear that Jason! Hopefully others can also verify it while we look at the underlying problem.
Comment 55 Brian Macomber 2017-05-16 21:50:17 UTC
Assuming I set the environment variable correctly, I'm seeing mixed results.  Seems better, but I'm still getting the locked files.
Comment 56 Samih 2017-05-16 22:39:31 UTC
Hello,

I'm using Visual Studio 2015 Update 3 and here is what worked for me:

- Uninstalling Xamarin v4.5.0.443
- Reinstalling the v4.2.1.62 (given by default via Control Panel => Visual Studio 2015 => Change)

And that's it. No need to close/open Visual Studio or to delete bin/obj, no compilation error anymore. Priceless.

Give it a try!
Comment 57 Heinrich Braasch 2017-05-17 02:58:16 UTC
Have tried envvar MSBUILDDISABLENODEREUSE=1
Does not appear to have any affect in my case.
Comment 58 Zahi Kramer 2017-05-17 08:55:23 UTC
The Env. variable MSBUILDDISABLENODEREUSE=1 is a great improvement , but not totally.
I see another process interfering : "vstest.discoveryengine.x86.exe" 
On Build this process came up and after i kill it i can compile.
Please check it also.
But the Env variable is killing the MSBuild Process i mentioned on the other post (closed duplicate).
Good workaround. Thanks , but keep investigating the vstest process.
Comment 59 Michel Moorlag 2017-05-17 08:57:38 UTC
I decided to rollback to the previous version because I have no more time to lose.
As suggested by Olexander Ivanitskyi I uninstalled Xamarin 4.5.0.443 from my computer and downloaded and installed Xamarin 4.4.0.34. On my Mac I downloaded and installed Xamarin iOS 10.8. and I am finally back on track. It took like 15 minutes and I can confirm that this works for me. So If there is no urgent reason to use the latest this is a good work around for now.
Comment 60 Heinrich Braasch 2017-05-17 10:09:36 UTC
I rolled back to Visual Studio 2017 15.0 by uninstalling 15.2 (26430.6), then reinstalling 15.0 from scratch. Took me about 3 hours.

However, all is working a charm again.

One curious thing though, slightly off-track. While hitting this locking problem I was busy debugging a serious slowdown in execution speed when running my app on a physical device (on simulator it still performs well), but after this rollback, the on-device execution is now back to that of the simulator... Somehow some serious issues crept in during the updates.

Just my pennies worth, in case it might help somebody.
Comment 61 Jason Brown 2017-05-17 10:31:45 UTC
The problem happened to me again today even with the MSBUILDDISABLENODEREUSE=1 environment variable. I used Olexander Ivanitskyi suggestion and rolled my VS2015.3 back to 4.4.0.34 and iOS10.8 - which took about 20 minutes.

Now everything's working fine.
Comment 62 Vladislav Kosev 2017-05-17 11:37:56 UTC
Has someone tried creating a brand new project to see if the problem exhibits there? They didn't see it in alpha/beta testing so this must be some case with older projects.
Comment 63 Joshua Poling 2017-05-17 12:48:48 UTC
I've only experienced the issue in solutions containing multiple projects / PCL's. It seems that MSBuild is not stopped after debugging, which is possibly causing the issue. I am noticing multiple MSBuilds starting on continuous builds. I've only been able to solve the issue by stopping all instances of MSBuild, deleting all files in the obj\Debug folder, and PCL Debug folders.
Comment 64 Vladislav Kosev 2017-05-17 12:50:44 UTC
We have a problem with a solution with a single PCL and it's pretty consistent. I don't think its MSBuild. Maybe it is the longer build...
Comment 65 Vladislav Kosev 2017-05-17 14:13:22 UTC
The environment variable didn't help much. It is *maybe* better, but not gone. I had 3 files locked at one time and all of them were PCLs, not the platform specific ones. Only PCLs get locked. Whatever that means...
Comment 66 Vladislav Kosev 2017-05-17 14:32:54 UTC
Just some more info - I created a brand new empty project and there there were alwatys locks, but two-three of them and the build passed. I'm guessing its because it is empty and builds fast.
Comment 67 Vladislav Kosev 2017-05-17 14:51:08 UTC
I take that back. Just had a Android type library locked. 4 files at a time!
Comment 68 Daniel Cazzulino 2017-05-17 15:35:17 UTC
Just to verify: this occurs only when XF is referenced, right? Or does it also repro if no XF is in use?

Thanks
Comment 69 Vladislav Kosev 2017-05-17 15:37:29 UTC
I haven't tried. What test do you want me to conduct and I can try and run it in a few hours? If I can help fix this faster, by all means, write away!
Comment 70 rohan bethune 2017-05-17 15:53:17 UTC
Having commented yesterday that running VS in ADMIN mode seemed to alleviate the pain somewhat - today (after a MAC reboot), issue now resurfaced. I can confirm that the locking issue occurs regardless of dev approach used , i.e a pure XF solution (either pure code behind or XAML based) , Xamarin.iOS (using storyboards)  or Xamarin.Android (axml files) .  I get locked assemblies. The only common theme between all three is that I use PCL's for shared code.  Also  , applying MSBUILDDISABLENODEREUSE=1 didnt help me. My solution now would be to downgrade to VS 2017 (15) as this appears to work.
Comment 71 TamasA 2017-05-17 15:59:03 UTC
I had the same issue after updating Visual Studio and Xamarin to the latest stable version (15.2 (26430.6), 4.5.0.443). 

It was basically impossible to work with it without restarting VS after each debug session, we lost a lot of time because of this, since we have a large Xamarin Forms solution, and it takes a lot of time to load and build.

So I decided to give a shot to the Preview version of VS (before downgrading), and it works without issues. VS: 15.3 (26510.0-Preview), Xamarin: 4.6.01586 (but 4.5 also worked with this VS version.)
Comment 72 Edward Brey 2017-05-17 16:41:29 UTC
For me, the file is locked by devenv.exe, not a MSBuild process, so I wasn't surprised to find that MSBUILDDISABLENODEREUSE did not help.
Comment 73 Daniel Cazzulino 2017-05-17 16:54:27 UTC
Could others also try 15.3 preview to see if that fixes the issue?
Comment 74 Brian Macomber 2017-05-17 18:13:32 UTC
Ive done the following and have less issues so far.  Not sure it's all related, but I appear to have very less frequent lock issues.

updated to Xamarin.Forms 2.3.4.247

re-installed all nuget packages (trying to resolve crazy build errors, I think I had out of sync packages)

set the MSBUILDDISABLENODEREUSE var
Comment 75 Lucian POPESCU 2017-05-17 18:51:52 UTC
I can see that some are complaining about the bug still being present in VS 15.2 (26430.6). That is not my case, though. Complete version info below:

Microsoft Visual Studio Professional 2017
Version 15.2 (26430.6) Release
VisualStudio.15.Release/15.2.0+26430.6
Microsoft .NET Framework
Version 4.6.01586

Installed Version: Professional

Visual Basic 2017   00369-60000-00001-AA352
Microsoft Visual Basic 2017

Visual C# 2017   00369-60000-00001-AA352
Microsoft Visual C# 2017

Common Azure Tools   1.9
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Merq   1.1.17-rc (cba4571)
Command Bus, Event Stream and Async Manager for Visual Studio extensions.

Mono Debugging for Visual Studio   Mono.Debugging.VisualStudio
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager   4.2.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

VSColorOutput   2.5
Color output for build and debug windows - http://mike-ward.net/vscoloroutput

Xamarin   4.5.0.443 (c871575)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android SDK   7.3.0.13 (448f54f)
Xamarin.Android Reference Assemblies and MSBuild support.

Xamarin.iOS and Xamarin.Mac SDK   10.10.0.30 (30b6e87)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.
Comment 76 Lucian POPESCU 2017-05-17 19:04:26 UTC
LE: Just to be clear: I am NOT using Xamarin.Forms.
Comment 77 Lyndon Hughey 2017-05-17 21:51:19 UTC
As others have mentioned, the issue is less frequent when using visual studio in admin mode.  Unfortunately, I'm using mapped folders on parallels which are not accessible via VS when admin mode.  Grr...
Comment 78 Brendan Zagaeski (Xamarin Support) 2017-05-17 22:41:51 UTC
> Could others also try 15.3 preview to see if that fixes the issue?

To provide a bit more guidance about this request, the idea would be to install the Visual Studio 2017 Preview from https://www.visualstudio.com/vs/preview/.  This will install a second instance of Visual Studio 2017 _alongside_ the existing non-preview 15.2 version, so you can continue to use the 15.2 version side-by-side as needed.

The question to any users who might have a chance to try using the Visual Studio 2017 version 15.3 preview would be whether you see the same result as in Comment 71, where the file locking is no longer an issue.  That could be an additional useful clue in pointing toward what has changed in Xamarin to cause this issue in both Visual Studio 2015 and Visual Studio 2017.


Thanks!
Brendan
Xamarin Support
Comment 79 wil 2017-05-18 00:14:57 UTC
Just tried with Visual studio community preview and same issue.
Comment 80 Matt 2017-05-18 00:20:44 UTC
I tried using 15.3 preview, and still have the same issue.
Comment 81 Tuyen Duc Vu 2017-05-18 02:38:17 UTC
The same issue over here. Really frustrated :(
Comment 82 Heinrich Braasch 2017-05-18 05:20:49 UTC
I also tried using 15.3 preview and the problem remains. Not a fix.
Comment 83 Sascha Schwegelbauer 2017-05-18 07:26:13 UTC
Same problem here with the current "stable" Xamarin version.
Honestly guys: did you ever use your own "stable"-versions?
I have tested it on three different machines (including a completely new installed windows) and it's the same problem on all three machines.
Ah, and btw: your "Xamarin.Apple.Sdk.targets"-file is also buggy, see here: 
http://stackoverflow.com/questions/43913048/xamarin-ios-build-error-msb4096-referencecopylocalpaths-does-not-define-a-val
Comment 84 Philipp Sumi 2017-05-18 08:16:05 UTC
Strange enough, I have a test project where killing MsBuild.exe allows me to build again, while my production project is shot after one build and requires a restart, which takes ages anyway.
Comment 85 Vladislav Kosev 2017-05-18 08:21:58 UTC
There is a program called Lock Hunter, which allows unlocking the file without restarting VS. Its something...
Comment 86 TamasA 2017-05-18 08:35:30 UTC
comment  80 : Maybe try to update Xamarin as well (although as I mentioned before, it worked for me without this). They have a new tool for updating the Xamarin Extension: https://marketplace.visualstudio.com/items?itemName=Xamarin.XamarinUpdater (it updated the Mono Debugging as well)*

Also.. properly clean the your solution folder before doing the Rebuild. To be safe I use this powershell command a few times a day (since VS usually can not clean all the generated Xamarin files during the Clean):

Get-ChildItem .\ -include bin,obj -Recurse | foreach ($_) { remove-item $_.fullname -Force -Recurse }



comment 83 : yes, you are right, basically every second "stable" is broken in some way, maybe they not even try to build their own Forms solution with the new tool before releasing it. So what we do is: we only let one team member to update :/ and if everything OK, other can do it safely. (This time I was the lucky one :) )


* here is my version log:

Microsoft Visual Studio Professional 2017 Preview (2)
Version 15.3 (26510.0-Preview) Preview
VisualStudio.15.Preview/15.3.0-Preview+26510.0
Microsoft .NET Framework
Version 4.6.01586

Installed Version: Professional

Visual Basic 2017   00369-60000-00001-AA760
Microsoft Visual Basic 2017

Visual C# 2017   00369-60000-00001-AA760
Microsoft Visual C# 2017

Visual C++ 2017   00369-60000-00001-AA760
Microsoft Visual C++ 2017

Application Insights Tools for Visual Studio Package   8.7.00411.1
Application Insights Tools for Visual Studio

ASP.NET and Web Tools 2017   15.0.30504.0
ASP.NET and Web Tools 2017

ASP.NET Core Razor Language Services   1.0
Provides languages services for ASP.NET Core Razor.

ASP.NET Template Engine 2017   15.0.30504.0
ASP.NET Template Engine 2017

Common Azure Tools   1.9
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

JavaScript Language Service   2.0
JavaScript Language Service

JavaScript Project System   2.0
JavaScript Project System

JavaScript UWP Project System   2.0
JavaScript UWP Project System

JetBrains ReSharper Ultimate 2016.3.2    Build 107.0.20170126.120331
JetBrains ReSharper Ultimate package for Microsoft Visual Studio. For more information about ReSharper Ultimate, visit http://www.jetbrains.com/resharper. Copyright © 2017 JetBrains, Inc.

Merq   1.1.17-rc (cba4571)
Command Bus, Event Stream and Async Manager for Visual Studio extensions.

Microsoft Visual Studio VC Package   1.0
Microsoft Visual Studio VC Package

Mono Debugging for Visual Studio   Mono.Debugging.VisualStudio
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager   4.3.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

TypeScript   2.2.0.0
TypeScript tools for Visual Studio

Visual Studio Code Debug Adapter Host Package   1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

Visual Studio Tools for Universal Windows Apps   15.0.26510.00
The Visual Studio Tools for Universal Windows apps allow you to build a single universal app experience that can reach every device running Windows 10: phone, tablet, PC, and more. It includes the Microsoft Windows 10 Software Development Kit.

VisualStudio.IoT   1.0
Package with IoT components for Visual Studio

VisualStudio.Mac   1.0
Mac Extension for Visual Studio

Xamarin   4.6.0.560 (33bfa20)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android SDK   7.3.0.13 (448f54f)
Xamarin.Android Reference Assemblies and MSBuild support.

Xamarin.iOS and Xamarin.Mac SDK   10.10.0.30 (30b6e87)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.
Comment 87 Sherlock 2017-05-18 08:43:39 UTC
I also have this issue.  VS2017 15.2, Xamarin 4.5.0.443.
Comment 88 danielferenczi 2017-05-18 08:49:56 UTC
Just to contribute to this awkward bugreport i've noticed that changing in Android layout files (.axml) doesn't seem to "invoke" the problem. I can change these files and still clean/build without getting stuck on copying dlls. 

Just downloaded Lock Hunter and it works pretty smooth. Having 3 windows of lock hunter open, one for each dll that constantly get locked and just delete them there. No need to restart VS. Even though this works I don't want to praise/commend this work-around since we NEED A REAL FIX! This is so awkward on behalf of Microsoft.
Comment 89 danielferenczi 2017-05-18 08:56:57 UTC
Never mind! Files got locked now when just changing the .axml files.
Comment 90 Denis 2017-05-18 08:57:33 UTC
I also have this issue. VS2017 15.2 (26430.6), Xamarin 4.5.0.443.

I typically clean solution, switch to release mode, switch back to debug and try again. Works 90% of the time and if it doesn't, repeat :p

I dare not rollback as others have as the whole Xamarin development environment in general seems so fragile, I'll wait for a 100% fix and live with the annoyance for now unfortunately. The price we pay for being on the cutting edge eh?
Comment 91 Michel Moorlag 2017-05-18 11:41:12 UTC
I partly agree with you Dennis. True Xamarin is cutting edge stuff, but according to this bug report this is not a lost incident or something. I agree more with Sascha Schwegelbauer that a little bit of testing could have prevented this nasty bug from entering a "stable" release. If the Xamarin team can build such great stuff they must be able to create some simple unit tests I would guess? There are developers that have deadlines to make and live form this stuff so why the rush?
Comment 92 aaron@veeprox.com 2017-05-18 13:43:23 UTC
same issue for me as well - 

Microsoft Visual Studio Professional 2017 
Version 15.2 (26430.6) Release
VisualStudio.15.Release/15.2.0+26430.6
Microsoft .NET Framework
Version 4.6.01586

Installed Version: Professional

Visual Basic 2017   00369-60000-00001-AA062
Microsoft Visual Basic 2017

Visual C# 2017   00369-60000-00001-AA062
Microsoft Visual C# 2017

Visual C++ 2017   00369-60000-00001-AA062
Microsoft Visual C++ 2017

Visual F# 4.1   00369-60000-00001-AA062
Microsoft Visual F# 4.1

ASP.NET and Web Tools 2017   15.0.30503.0
ASP.NET and Web Tools 2017

ASP.NET Web Frameworks and Tools 2017   5.2.50303.0
For additional information, visit https://www.asp.net/

Azure App Service Tools v3.0.0   15.0.30209.0
Azure App Service Tools v3.0.0

Azure Data Lake Node   1.0
This package contains the Data Lake integration nodes for Server Explorer.

Azure Data Lake Tools for Visual Studio   2.2.5000.0
Microsoft Azure Data Lake Tools for Visual Studio

Common Azure Tools   1.9
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Dummy Text Generator   1.2.13
Easily insert dummy text into the editor in Visual Studio. Lorem Ipsum and other vocabularies are supported.

Fabric.DiagnosticEvents   1.0
Fabric Diagnostic Events

GitHub.VisualStudio   2.2.0.11
A Visual Studio Extension that brings the GitHub Flow into Visual Studio.

JavaScript Language Service   2.0
JavaScript Language Service

JavaScript Project System   2.0
JavaScript Project System

JavaScript UWP Project System   2.0
JavaScript UWP Project System

JetBrains ReSharper Ultimate 2017.1.2    Build 108.0.20170428.75743
JetBrains ReSharper Ultimate package for Microsoft Visual Studio. For more information about ReSharper Ultimate, visit http://www.jetbrains.com/resharper. Copyright © 2017 JetBrains, Inc.

KofePackagePackage Extension   1.0
KofePackagePackage Visual Studio Extension Detailed Info

Merq   1.1.17-rc (cba4571)
Command Bus, Event Stream and Async Manager for Visual Studio extensions.

Microsoft Azure Hive Query Language Service   2.2.5000.0
Language service for Hive query

Microsoft Azure Tools   2.9
Microsoft Azure Tools for Microsoft Visual Studio 2017 - v2.9.50131.1

Microsoft MI-Based Debugger   1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Microsoft Visual Studio VC Package   1.0
Microsoft Visual Studio VC Package

Mono Debugging for Visual Studio   Mono.Debugging.VisualStudio
Support for debugging Mono processes with Visual Studio.

Node.js Tools   1.3.50417.1
Adds support for developing and debugging Node.js apps in Visual Studio

NuGet Package Manager   4.2.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

Open Command Line   2.1.179
Opens a command line at the root of the project. Support for all consoles such as CMD, PowerShell, Bash etc. Provides syntax highlighting, Intellisense and execution of .cmd and .bat files.

SQL Server Data Tools   15.1.61702.140
Microsoft SQL Server Data Tools

ToolWindowHostedEditor   1.0
Hosting json editor into a tool window

TypeScript   2.2.2.0
TypeScript tools for Visual Studio

Visual Studio Tools for Apache Cordova   15.113.6201.1
Visual Studio Tools for Apache Cordova

Visual Studio Tools for Universal Windows Apps   15.0.26430.06
The Visual Studio Tools for Universal Windows apps allow you to build a single universal app experience that can reach every device running Windows 10: phone, tablet, PC, and more. It includes the Microsoft Windows 10 Software Development Kit.

WakaTime   1.0


Web Compiler   1.11.326
Compiler for LESS, Sass and CoffeeScript files

Xamarin   4.5.0.443 (c871575)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android SDK   7.3.0.13 (448f54f)
Xamarin.Android Reference Assemblies and MSBuild support.

Xamarin.iOS and Xamarin.Mac SDK   10.10.0.30 (30b6e87)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.
Comment 93 Joaquin Jares 2017-05-18 14:39:25 UTC
My latest working theory is that this is absolutely related to the unit test discovery (mentioned a few comments above). Is anybody that's hitting this bug NOT using unit tests? That will mean there's something else happening too.

Thanks,
joj
Comment 94 Vladislav Kosev 2017-05-18 14:41:03 UTC
I'm not using unit tests.
Comment 95 Brian Macomber 2017-05-18 14:41:54 UTC
I don't have any unit tests in my solution right now.

2 Forms PCL dlls
3 Platform specific class lib (UWP, iOS, Droid)
3 Platform App exe (UWP, iOS, Droid)
Comment 96 Jeremy Marcus 2017-05-18 14:42:01 UTC
I'm hitting this issue and I'm not using Unit Tests. **ducks head**
Comment 97 Vladislav Kosev 2017-05-18 14:43:35 UTC
I can't believe how many people are replying instantly... :) Everyone is on F5
Comment 98 Joaquin Jares 2017-05-18 15:09:16 UTC
Thanks, guys. I'm very close to a solution. If anyone wants to try a possible workaround (this will only work on 2017, though... so just a workaround), go to Properties on the project where the dll is blocking, go to Build, hit Advanced and change Debugging Information to Portable. If my theory is correct, that should make the build work. If it's not, please do tell. I'm basing my fix on that theory being correct :)

Thanks again
Comment 99 Joaquin Jares 2017-05-18 15:10:20 UTC
After that change, Clean Solution. I should have mentioned that.
Comment 100 Vladislav Kosev 2017-05-18 15:12:16 UTC
I will test this later in the day.

We're with you Joaquin!!
(just don't do that again:))
Comment 101 Homero Lara 2017-05-18 15:20:25 UTC
Hi Joaquin, your suggested work-around didn't work for me. I made the changes but I still get the same results.

Thanks for the update.
Comment 102 Vladislav Kosev 2017-05-18 15:22:22 UTC
You should probably let us test your theories before you post an update.
Comment 103 Vladislav Kosev 2017-05-18 15:22:39 UTC
I meant fix. Sorry.
Comment 104 Brendan Zagaeski (Xamarin Support) 2017-05-18 15:29:37 UTC
Thanks for the quick replies all.




## Note to the Xamarin team and the users on this bug

I have a fairly strong suspicion that any candidate fix that can be found to resolve Bug 56587 that I filed and marked as a "depends on" of this bug yesterday might resolve issue for all scenarios.  That bug provides a detailed characterization of the probability of hitting the issue consistently in a scenario related to a Xamarin.Forms template solution as long as the solution includes a Xamarin.Android project.

The Xamarin team has another consistent way to replicate the problem using a solution that includes a Xamarin.Android project, a PCL library, and a Unit Test project.

Both scenarios will be tested against candidate fixes, and any successful candidate fixes or workarounds will be provided to users as soon as possible for further verification on various scenarios.




## Bookkeeping note

For thorough bookkeeping I will also record the regression status on this bug under "Is this bug a regression?"  There is little doubt based on the user reports and the characterization of the particular scenario on Bug 56587 that this behavior is a change compared to Xamarin.VisualStudio 4.4.0.34 (3f99c5a).




Best,
Brendan
Xamarin Support
Comment 105 Diego P. 2017-05-18 15:38:44 UTC
Joaquin the fix not work for me.

Brendan, I dont use iOS or TEST, only Android now.


The error img:
http://i63.tinypic.com/1z5u1qt.png


msg:

Severity	Code	Description	Project	File	Line	Suppression State
Error		Unable to copy file "obj\Debug\AppName.dll" to "bin\Debug\AppName.dll". The process cannot access the file 'bin\Debug\AppName.dll' because it is being used by another process.	AppName			
Error		Could not copy "obj\Debug\AppName.dll" to "bin\Debug\AppName.dll". Exceeded retry count of 10. Failed.	AppName
Comment 106 Joaquin Jares 2017-05-18 17:32:25 UTC
A user reports this:

This problem has gone away on quite a few machines if you clear the .vs folder, delete bin, obj, suo files, and then disable "Shared Runtime" on the android projects.

I'm still on my previous path, but I'm posting it here in case it helps someone.
Comment 107 Matt 2017-05-18 17:54:42 UTC
Hi Joaquin the fix didn't work for me either.
Comment 108 Daniel Cazzulino 2017-05-18 17:57:22 UTC
Also, just to make sure: this only happens when Android apps are involved, not for iOS?
Comment 109 Brian Macomber 2017-05-18 18:13:49 UTC
I also tried setting the debug from full to portable, still seeing some file locks.  I have noticed it doesn't happen very much when building iOS...mainly UWP and Droid...but I think my solution is building the Droid projects when targeting UWP, so it could just be a Droid project issue.
Comment 110 Brendan Zagaeski (Xamarin Support) 2017-05-18 18:16:36 UTC
> This problem has gone away on quite a few machines if you clear the .vs folder

Note that the test case on Bug 56587 does not include an initial .vs folder, and it consistently demonstrates the issue starting from the clean test case, so users should note that at best this workaround would only stop the issue for the initial load of the solution.  Reloading the solution would potentially bring back the issue until the .vs folder was deleted again.




> this only happens when Android apps are involved, not for iOS?

The test scenario on Bug 56587 also demonstrates the problem when the iOS app project is built, but interestingly, the problem stops once the Android project is removed from the solution (even though only the same 3 projects (2 PCLs and 1 iOS project) are being built in both cases).


So I believe we can ask a slightly more specific question for any users who might be seeing this issue, on the chance it might help the Xamarin team for thorough data gathering.




## QUESTION TO USERS for narrower additional data gathering based on Comment 108

Has any user been hitting this issue consistently in a solution that does not _contain_ any Xamarin.Android project (regardless of whether that project is being built)?



(2 or 3 user reports confirming whether it is possible to hit the issue when non Xamarin.Android project is present in the solution should be sufficient.  Thanks!)
Comment 111 Cameron 2017-05-18 18:36:04 UTC
I'm joining in on this conversation too. I'm running VS Community 2017 w/ Xamarin 4.5.0.443. My Android project has issues being built. I have no unit tests either. It does seem to help to flip configuration modes and then rebuild. That seems to resolved the locked error.

Thanks
Comment 112 Allan 2017-05-18 18:41:26 UTC
I only have the problem with Android projects.    The problem was "fixed" by deleting the bin, obj, user and .vs folder with Visual Studio closed.  And then disabling "Shared Runtime" one the solution is loaded again.

I just reproduced the problem by purely enabling "Shared Runtime" again on the Android project.    Just note, disabling it again does not fix the problem until Visual Studio has been closed and the above steps performed.   

This is reproducible on this solution, so may be the source of "data gathering" as mentioned by Brendan Zagaeski.
Comment 113 Lyndon Hughey 2017-05-18 19:14:46 UTC
I've not had another occurrence of this issue since I removed my Android project from the solution.  This is surprising because I was experiencing this issue when building the iOS project of this PCL Forms solution.
Comment 114 Lucian POPESCU 2017-05-18 19:17:47 UTC
I might have spoken too soon about the bug being gone. The bug is still there and the only projects included in the solution are an Android one and a PCL one, so this is definitely Android related.

Version info again:

Microsoft Visual Studio Professional 2017
Version 15.2 (26430.6) Release
VisualStudio.15.Release/15.2.0+26430.6
Microsoft .NET Framework
Version 4.6.01586

Installed Version: Professional

Visual Basic 2017   00369-60000-00001-AA352
Microsoft Visual Basic 2017

Visual C# 2017   00369-60000-00001-AA352
Microsoft Visual C# 2017

Common Azure Tools   1.9
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Merq   1.1.17-rc (cba4571)
Command Bus, Event Stream and Async Manager for Visual Studio extensions.

Mono Debugging for Visual Studio   Mono.Debugging.VisualStudio
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager   4.2.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

VSColorOutput   2.5
Color output for build and debug windows - http://mike-ward.net/vscoloroutput

Xamarin   4.5.0.443 (c871575)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android SDK   7.3.0.13 (448f54f)
Xamarin.Android Reference Assemblies and MSBuild support.

Xamarin.iOS and Xamarin.Mac SDK   10.10.0.30 (30b6e87)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.
Comment 115 Brendan Zagaeski (Xamarin Support) 2017-05-18 19:32:57 UTC
## Status update

Thanks very much everyone for all of the responses and testing.  The engineering team now has a strong candidate for the root cause of this issue and is working on correcting and testing that suspected root cause.

The culprit appears to be the tool that converts the non-portable .pdb debugging symbols generated by `csc` on Windows to the .mdb format for compatibility debugging with the Mono runtime.  The converter tool switched from reading assembly information into _memory_ to reading it directly from the _file system_ (introducing a new source of file locking).  This change was introduced indirectly via an update for a dependency on the Cecil library (https://github.com/mono/cecil).

I will keep the bug updated today as the follow-up results become available from the engineering team.
Comment 116 Diego P. 2017-05-19 00:32:53 UTC
Thanks Brendan, I wait for final solutions or workaround, thanks!!!
Comment 117 Michel Moorlag 2017-05-19 07:23:11 UTC
Thank you Brendan, it is good to hear there is some light at the end of the tunnel :)
At first I was afraid the Xamarin team was just ignoring this but I was wrong.
If there is something I can test for you I am happy to do so.
And for the record, I really love Xamarin (Forms). It gives us .net devs really great powers. But let me quote uncle Ben: "with great power comes great responsibility" if you know what I mean ;)
Comment 118 ralphcgutierrez 2017-05-19 13:10:52 UTC
Thanks Brendan, Looking forward for the solutions.
Comment 119 Edward Brey 2017-05-19 13:18:41 UTC
In my case the lockout went from nearly 100% occurance to 0% by unloading the Android project. This is a workflow that mainly builds and debugs in UWP (because it is fastest).

The Xamarin Android tooling seems to do lots of work in the background. Often, when the VS UI locks up, Task Manager shows at least once Java compilation process running, even if I'm not actually building the Android project at the moment. It would be nice if I could tell it to just chill until I actually want to build on Android, but without having to unload the Android project.
Comment 120 Vladislav Kosev 2017-05-19 14:33:31 UTC
I can confirm that unloading the Android project removes the problem. 20+ builds so far on UWP and iOS and no locks.
Comment 121 Philipp Sumi 2017-05-19 14:38:12 UTC
Same here - switched over to iOS and unloaded, no blocks anymore. And just discovered that the breakpoints in iOS aren't hit anymore. Srsly. Guys!
Comment 122 Brian Macomber 2017-05-19 14:39:29 UTC
Unloading the android project helps for me, but I've noticed the following behavior with my android project unloaded, starting up the UWP exe

My solution is setup in this dependency order

Core PCL dll
App PCL dll
Platform exe => each references a matching dll containing common platform renderers, etc

When I make changes to code in the Core PCL...lock issue every time I build uwp..must delete the dll

When I make changes to the App PCL, no locks.
Comment 123 Vladislav Kosev 2017-05-19 15:07:20 UTC
Spoke too soon. Had a lock. Nevertheless, they are severely more rare.
Comment 124 Vladislav Kosev 2017-05-19 15:07:56 UTC
Now I have a lock every build. I don't know what triggered it.
Comment 125 xamarin-release-manager 2017-05-19 16:02:08 UTC
Fixed in version 4.5.0.473 (d15-2)

Author: joj
Commit: 030924d98ba23d814e0183b85f297c568b4743ed (xamarin/XamarinVS)
Comment 126 Brendan Zagaeski (Xamarin Support) 2017-05-19 16:27:42 UTC
## Status update

I have tested the candidate change from Comment 125 in an unsigned local test build for my particular local test scenario in Bug 56587, Comment 5.  The candidate change is verified in that scenario.

I will update the bug again as the change makes its way into a signed build (that is suitable for distribution to users).


As suspected (Comment 115), the root issue addressed by the change in Comment 125 was a change in behavior of the Cecil library that lead to more file locks being taken.
Comment 127 Matt 2017-05-19 16:40:56 UTC
Thanks guys. Any idea how long until we get the patch?
Comment 128 Brendan Zagaeski (Xamarin Support) 2017-05-19 16:53:17 UTC
The tentative goal at the moment is to have builds available within no more than a couple business days.  I will keep the status up-to-date as the builds and integration move forward in case there are any unexpected hiccups, and will advise if builds suitable for distribution become available sooner (for example, before they are published via the updaters).
Comment 129 Matt 2017-05-19 17:20:44 UTC
Thanks Brendan, appreciate your guy's quick responses. How do we let your managers know?
Comment 130 Brendan Zagaeski (Xamarin Support) 2017-05-20 17:22:30 UTC
Glad to have helped keep the bug up-to-date, and no need to worry about extra feedback for our managers.  They will be sure to look back over this bug to see how things went, so that's all set.  Thanks!


Quick update: So far the integration into distributable builds is on-track.
Comment 131 abdullah 2017-05-22 13:33:53 UTC
when we'll have the update for fixing this bug!
Comment 132 Nuno Mendes 2017-05-22 16:32:19 UTC
Desperately waiting for the update to fix this issue!
Comment 133 Jason Couture 2017-05-22 16:40:57 UTC
Any status update?
Comment 134 Brendan Zagaeski (Xamarin Support) 2017-05-22 17:10:33 UTC
Work is still on-track to have the builds available within 2 business days of Comment 128, with a tentative plan for release tomorrow.  As before, I will continue to keep the status up-to-date as the builds and integration move forward in case there are any unexpected hiccups, and will advise if builds suitable for distribution become available sooner (for example, before they are published via the updaters).
Comment 135 Brendon Paul 2017-05-23 02:04:05 UTC
For those looking for a temp solution, I've had very good success (so far my last 5 testing build/deploys!) in keeping the debug folder open, and deleting the appname.mdb, appname.pdb and appname.dll files - in that specific order; why the specific order seems to matter is a bit beyond me (perhaps killing of the mdb file triggers some background process to die?), but it seems good so far.

I would note that in my tests, I would build, wait for the lock up, then delete the files - just to be sure that things were actually locking up.  Will post back later today if this winds up failing at all, but so far 5 for 5 is pretty good, given that I was mucking about on most builds (occasionally things just worked properly, but it was few and far between) ....
Comment 136 Brendon Paul 2017-05-23 03:57:28 UTC
Quick update - I've done this several dozen times now, and it seems to work quite well.   The only issue I've experienced is deleting the files out of order and twice deleting the mdb & pdb and forgetting the dll.  In both cases things locked up again.  Cleaning and building just the PCL libraries recreated the required files and let me continue.
Comment 137 abdullah 2017-05-23 08:05:16 UTC
Brendon Paul  thank this made it work
Comment 138 Paul Sinnema 2017-05-23 08:43:10 UTC
We use 2 PCL libraries. It solves it for 1 PCL. The other still get locked.
Comment 139 Saurabh Paunikar 2017-05-23 12:26:01 UTC Comment hidden (obsolete)
Comment 140 Michel Moorlag 2017-05-23 13:12:51 UTC
Hi Saurabh,

Can you build the Xamarin Evolve 2016 app from https://github.com/xamarinhq/app-evolve ?
Comment 141 Jeremy Kolb 2017-05-23 14:53:19 UTC
I hope you guys can add some tests to catch this in the future.
Comment 142 Brendan Zagaeski (Xamarin Support) 2017-05-23 15:55:38 UTC
## Status update and follow-up on Comment 139

Comment 139 (by the Xamarin scenario running team) is unfortunately probably not a meaningful verification, so I have marked it as obsolete.  There is a decent chance that the scenarios tested in Comment 139 would not have hit this problem even _without_ the fix.

I will proceed to verify my particular local test scenario from Bug 56587 (where I was consistently able to hit the issue, and where I recorded the probability of hitting the issue) with today's planned release build as a final local verification.  The Xamarin team will also monitor user feedback after the release to watch for potential additional reports of the issue for other scenarios.  (The currently available information about the cause and resolution of the issue suggests that the fix is complete for all reported scenarios.  So at this time it is not expected that any new scenarios will be reported after the release.)
Comment 143 lecnier.freeman 2017-05-23 19:43:56 UTC
This bug is marked resolved but I don't see any update in Visual Studio Installer?
Comment 144 Andy 2017-05-23 20:00:58 UTC
When the issue is fixed, which version of visual studio preview will we have to install?
Comment 145 Brendan Zagaeski (Xamarin Support) 2017-05-23 23:02:42 UTC
## Status update

The candidate fix for this issue has now been released to the Stable and Beta updater channels [1] for Visual Studio 2015 and below. The change has also been integrated successfully into the upstream Visual Studio 2017 packaging process, but unfortunately the service release for the full Visual Studio 2017 encountered a separate issue during the finalization process unrelated to the Xamarin workload, so it is not being released today.  The corresponding Visual Studio 2017 service release is still tentatively planned for this week, but in the mean time the Xamarin team is considering alternate approaches for Visual Studio 2017 users to apply this particular fix.  I will update the bug report as soon as there is any additional news on that topic.

[1] See "Change the Updates Channel in Visual Studio 2015 and earlier" on https://developer.xamarin.com/recipes/cross-platform/ide/change_updates_channel/#visualstudio
Comment 146 Jim Horvath 2017-05-24 01:11:55 UTC
Unbelievable.  My choice of Xamarin is going to get me fired.
My build/deploy times were already 3-5 minutes, this is completely unworkable.  It should have been an emergency revert the day of/after this was released.  Xamarin Stable.  Stable!
How much money did MS just spend on Build?  Might as well have taken that cash, put it in a pile, and set it on fire.
Comment 147 lecnier.freeman 2017-05-24 01:38:16 UTC
@jim Same history here, in my case I pushed for Xamarin at my work a year ago and they paid for 2 seats license, but after a 1.5 years struggling with piles and piles of bugs, my love for c# is not enough to keep buying their marketing, they keep doing demos like last week in msbuild to recruit new developers when they should first focus on fixing all bugs. My current fight at work is defending.net core, Xamarin is a lost battle.
Comment 148 Brendon Paul 2017-05-24 02:23:46 UTC
@jim, @lecnier - you might want to try my workaround above which involves deleting the mdb, pdb, and finally dll files in the PCL directory of your APP.

No guarantees it will work, but I've done 30+ builds since last night (both playing and actually working), and as long as I remember to do this prior to building/rebuilding/cleaning, it works 100% of the time.   I did see a poster above that said this only worked for 1 PCL in a multi-PCL scenario, however I'm not sure why; I have 2 PCLs along with an Android (& iOS - though currently disabled) project, and all works well.

I suspect that one could potentially even write these commands into a build event (my gut says POST build after a delay of X seconds on a successful build).
Comment 149 Brendon Paul 2017-05-24 02:26:24 UTC
As an aside - not defending Xamarin or MS here, and Xamarin usage has been a rocky road over the last few years, but I'm focused on getting a couple of critical builds right now for a demo, and thought I might help out others through my findings...
Comment 150 lecnier.freeman 2017-05-24 03:01:33 UTC
Thank You @Brendon Paul I just switched from VS to VS on Mac, xaml, intellisense and formatting is a work in progress but I cannot waste more time, I'm trying to update Xamarin.Android support libs to mono 7 version 25... and Xamarin.Forms to be able to use a play video nugget and kind of getting crazy, I uninstalled VS so many times, I thought was a problem with side by side preview version and stable one, event erase everything from the mac just in case, I couldn't imagine it was the mother of bugs in Xamarin, and what's really bother me is they always ask for a project to test the bug, Xamarin at least should test their project templates on every stable release or VS update and detect the bug before the community, they should respect more us and take more seriously what in software "stable" version means.
Comment 151 Andy 2017-05-24 03:22:48 UTC
I think it's ridiculous that Visual Studio 2017 removed the ability to select either stable, beta, or alpha channel for Xamarin. I guess my fear in moving to 2017 is now validated.
Comment 152 Elie Yacoub 2017-05-24 04:47:48 UTC
hi Brendon, even though the build for visual studio failed, this specific Xamarin update should be available through Xamarin Updater extension.
isn't why this updater has been released?
Comment 153 Allan 2017-05-24 06:44:54 UTC
The Android "shared runtime" locking problem we encountered on VS 2015 seems to be addressed in 4.5.0.475.   Checking all pc's and occurrences, but looking good.

Thank you!!!
Comment 154 Michel Moorlag 2017-05-24 08:14:34 UTC
I am using using Visual Studio 2015 update 3 and Xamarin 4.4.0.34. This morning I verified I was able to build and debug on both Android and IOS. Then I fired up Xamarin Studio Community on my Mac and searched for updates. I downloaded and installed all the updates available. Then I installed Xamarin 4.5.0.475 on my windows pc with Visual Studio. I rebooted my machine and cleaned my solution. I uninstalled my app from my Android phone. The good news is that I can build without any lockup for both Android and IOS. The bad news is that I can not debug anymore on both Android as IOS. The app gets deployed and I see the splashscreen. Halfways the app stops and I receive an error in visual studio.
I am seeing files not found exceptions like file Mono.Posix ?

I and the relevant part form my logging for Android:

Thread started:  #9
InspectorDebugSession(6): HandleTargetEvent: ThreadStarted
05-24 09:51:00.943 D/Mono    (23385): Image addref System.ComponentModel.TypeConverter[0xb875a398] -> System.ComponentModel.TypeConverter.dll[0xb923d9c0]: 2
05-24 09:51:00.943 D/Mono    (23385): Prepared to set up assembly 'System.ComponentModel.TypeConverter' (System.ComponentModel.TypeConverter.dll)
05-24 09:51:00.943 D/Mono    (23385): Assembly System.ComponentModel.TypeConverter[0xb875a398] added to domain RootDomain, ref_count=1
05-24 09:51:00.954 D/Mono    (23385): AOT: image 'System.ComponentModel.TypeConverter.dll.so' not found: dlopen failed: library "/data/app/com.fullwood.crystalx3-1/lib/arm/libaot-System.ComponentModel.TypeConverter.dll.so" not found
05-24 09:51:00.963 D/Mono    (23385): AOT: image '/usr/local/lib/mono/aot-cache/arm/System.ComponentModel.TypeConverter.dll.so' not found: dlopen failed: library "/data/app/com.fullwood.crystalx3-1/lib/arm/libaot-System.ComponentModel.TypeConverter.dll.so" not found
05-24 09:51:00.963 D/Mono    (23385): Config attempting to parse: 'System.ComponentModel.TypeConverter.dll.config'.
05-24 09:51:00.964 D/Mono    (23385): Config attempting to parse: '/usr/local/etc/mono/assemblies/System.ComponentModel.TypeConverter/System.ComponentModel.TypeConverter.config'.
05-24 09:51:00.964 D/Mono    (23385): Assembly Ref addref Newtonsoft.Json[0xb83dc090] -> System.ComponentModel.TypeConverter[0xb875a398]: 2
05-24 09:51:00.964 D/Mono    (23385): Assembly Ref addref System.ComponentModel.TypeConverter[0xb875a398] -> System[0xb876b048]: 10
Loaded assembly: System.ComponentModel.TypeConverter.dll [External]
05-24 09:51:01.004 D/Mono    (23385): Assembly Ref addref CrystalLight.Droid[0xb83c2940] -> Akavache[0xb83c6728]: 4
05-24 09:51:01.014 D/Mono    (23385): Assembly Ref addref CrystalLight.Droid[0xb83c2940] -> System.Reactive.Linq[0xb83f1628]: 6
05-24 09:51:01.014 D/Mono    (23385): Assembly Ref addref CrystalLight.Droid[0xb83c2940] -> System.Reactive.Core[0xb83ef980]: 6
05-24 09:51:01.015 D/Mono    (23385): Assembly Ref addref CrystalLight.Droid[0xb83c2940] -> FreshMvvm[0xb83d3df8]: 3
05-24 09:51:01.035 V/MyBroadcastReceiver-GCM(23385): GCM Registered: APA91bG9c6MzE1iSnzVj2DRWenPAHV_ETVj3pItsGEpsoJPSnpoNy0V5pAl3UAzPIYqJjJl3-LB8OTxCnp2KT9CHRDOIhg9uB05BlsIwZvAx1NKIBFH-fDiV-y7IQux9gUNJNQJdcbxM
05-24 09:51:01.036 D/Mono    (23385): Assembly Ref addref CrystalLight.Droid[0xb83c2940] -> Xamarin.Azure.NotificationHubs.Android[0xb8408bc0]: 2
The connection with the debugger has been lost. The target application may have exited.
System.IO.FileNotFoundException: Could not load file or assembly 'Mono.Posix, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one of its dependencies. The system cannot find the file specified.
File name: 'Mono.Posix, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756'
   at Mono.Debugging.Soft.SoftDebuggerSession.ResolveSymbolicLink(String path)
   at Mono.Debugging.Soft.SoftDebuggerSession.PathsAreEqual(String p1, String p2)
   at Mono.Debugging.Soft.SoftDebuggerSession.FindLocationByMethod(MethodMirror method, String file, Int32 line, Int32 column, Boolean& insideTypeRange)
   at Mono.Debugging.Soft.SoftDebuggerSession.FindLocationByType(TypeMirror type, String file, Int32 line, Int32 column, Boolean& genericMethod, Boolean& insideTypeRange)
   at Mono.Debugging.Soft.SoftDebuggerSession.ResolveBreakpoints(TypeMirror type)
   at Mono.Debugging.Soft.SoftDebuggerSession.HandleTypeLoadEvents(TypeLoadEvent[] events)
   at Mono.Debugging.Soft.SoftDebuggerSession.HandleEventSet(EventSet es)
   at Mono.Debugging.Soft.SoftDebuggerSession.EventHandler()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

InspectorDebugSession(6): HandleTargetEvent: TargetExited
InspectorDebugSession(6): Disposed


And for IOS is see something about a broken mono install?
Launching 'CrystalLight.iOS' on 'iPhone 5s iOS 10.3'...
Loaded assembly: /Users/mhgmoorlag/Library/Developer/CoreSimulator/Devices/F57843E5-DC9F-4B17-B172-4DD0A637DA87/data/Containers/Bundle/Application/124034C5-71D4-4486-9100-BFBF1EBB709B/CrystalLight.iOS.app/.monotouch-64/Xamarin.iOS.dll [External]
2017-05-24 09:41:57.068 CrystalLight.iOS[79924:22793982] warning: cant resolve internal call to "System.Threading.Thread::CurrentInternalThread_internal()" (tested without signature also)
2017-05-24 09:41:57.070 CrystalLight.iOS[79924:22793982] 
Your mono runtime and class libraries are out of sync.
2017-05-24 09:41:57.071 CrystalLight.iOS[79924:22793982] The out of sync library is: /Users/mhgmoorlag/Library/Developer/CoreSimulator/Devices/F57843E5-DC9F-4B17-B172-4DD0A637DA87/data/Containers/Bundle/Application/124034C5-71D4-4486-9100-BFBF1EBB709B/CrystalLight.iOS.app/.monotouch-64/mscorlib.dll
2017-05-24 09:41:57.071 CrystalLight.iOS[79924:22793982] 
When you update one from git you need to update, compile and install
the other too.
2017-05-24 09:41:57.072 CrystalLight.iOS[79924:22793982] Do not report this as a bug unless you're sure you have updated correctly:
you probably have a broken mono install.
2017-05-24 09:41:57.072 CrystalLight.iOS[79924:22793982] If you see other errors or faults after this message they are probably related
2017-05-24 09:41:57.073 CrystalLight.iOS[79924:22793982] and you need to fix your mono install first.
Loaded assembly: /Users/mhgmoorlag/Library/Developer/CoreSimulator/Devices/F57843E5-DC9F-4B17-B172-4DD0A637DA87/data/Containers/Bundle/Application/124034C5-71D4-4486-9100-BFBF1EBB709B/CrystalLight.iOS.app/.monotouch-64/System.dll [External]
Thread started:  #2
2017-05-24 09:41:57.396 CrystalLight.iOS[79924:22794211] critical: Stacktrace:
2017-05-24 09:41:57.397 CrystalLight.iOS[79924:22794211] critical: 
Native stacktrace:
2017-05-24 09:41:57.460 CrystalLight.iOS[79924:22794211] critical: 	0   CrystalLight.iOS                    0x000000010e8c1191 mono_handle_native_crash + 257
2017-05-24 09:41:57.460 CrystalLight.iOS[79924:22794211] critical: 	1   CrystalLight.iOS                    0x000000010e8ce260 mono_sigsegv_signal_handler + 288
2017-05-24 09:41:57.461 CrystalLight.iOS[79924:22794211] critical: 	2   libsystem_platform.dylib            0x000000011bd66bba _sigtramp + 26
2017-05-24 09:41:57.461 CrystalLight.iOS[79924:22794211] critical: 	3   ???                                 0x0000000000000000 0x0 + 0
2017-05-24 09:41:57.462 CrystalLight.iOS[79924:22794211] critical: 	4   CrystalLight.iOS                    0x000000010ea0fd39 finish_gray_stack + 121
2017-05-24 09:41:57.462 CrystalLight.iOS[79924:22794211] critical: 	5   CrystalLight.iOS                    0x000000010ea10594 major_finish_collection + 132
2017-05-24 09:41:57.462 CrystalLight.iOS[79924:22794211] critical: 	6   CrystalLight.iOS                    0x000000010ea0ca60 major_do_collection + 160
2017-05-24 09:41:57.463 CrystalLight.iOS[79924:22794211] critical: 	7   CrystalLight.iOS                    0x000000010ea0bfd9 sgen_perform_collection + 713
2017-05-24 09:41:57.463 CrystalLight.iOS[79924:22794211] critical: 	8   CrystalLight.iOS                    0x000000010ea0d6d3 sgen_gc_collect + 51
2017-05-24 09:41:57.464 CrystalLight.iOS[79924:22794211] critical: 	9   CrystalLight.iOS                    0x000000010ea84ad6 _ZL7pump_gcPv + 54
2017-05-24 09:41:57.464 CrystalLight.iOS[79924:22794211] critical: 	10  libsystem_pthread.dylib             0x000000011bd78aab _pthread_body + 180
2017-05-24 09:41:57.464 CrystalLight.iOS[79924:22794211] critical: 	11  libsystem_pthread.dylib             0x000000011bd789f7 _pthread_body + 0
2017-05-24 09:41:57.465 CrystalLight.iOS[79924:22794211] critical: 	12  libsystem_pthread.dylib             0x000000011bd781fd thread_start + 13
2017-05-24 09:41:57.465 CrystalLight.iOS[79924:22794211] critical: 
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================
The app has been terminated.
Launch failed. The app 'CrystalLight.iOS' could not be launched on 'iPhone 5s iOS 10.3'. Error: An error occurred while executing MTouch. Please check the logs for more details.
The app has been terminated.


Further I noticed after deploy and crash of the android app I can start it manually on my phone and the app seems to function correct. The IOS can't be started manually though.
Comment 155 softlion 2017-05-24 08:56:15 UTC
On Android debugging on simulator now fails and triggers this:

---------------------------
Microsoft Visual Studio
---------------------------
EXCEPTION: Mono.Debugging.Soft.DisconnectedException: The connection with the debugger has been lost. The target application may have exited. ---> System.IO.FileNotFoundException: Can not load 'Mono.Posix, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or its dependencies. File not found.

   at Mono.Debugging.Soft.SoftDebuggerSession.ResolveSymbolicLink(String path)

   at Mono.Debugging.Soft.SoftDebuggerSession.PathsAreEqual(String p1, String p2)

   at Mono.Debugging.Soft.SoftDebuggerSession.FindLocationByMethod(MethodMirror method, String file, Int32 line, Int32 column, Boolean& insideTypeRange)

   at Mono.Debugging.Soft.SoftDebuggerSession.FindLocationByType(TypeMirror type, String file, Int32 line, Int32 column, Boolean& genericMethod, Boolean& insideTypeRange)

   at Mono.Debugging.Soft.SoftDebuggerSession.ResolveBreakpoints(TypeMirror type)

   at Mono.Debugging.Soft.SoftDebuggerSession.HandleTypeLoadEvents(TypeLoadEvent[] events)

   at Mono.Debugging.Soft.SoftDebuggerSession.HandleEventSet(EventSet es)

   at Mono.Debugging.Soft.SoftDebuggerSession.EventHandler()

   --- End of inner exception stack trace ---
---------------------------
OK   
---------------------------
Comment 156 Brendan Zagaeski (Xamarin Support) 2017-05-24 09:14:52 UTC
I have filed follow-up Bug 56787 to organize the investigation of the issue from Comment 154 and Comment 155.  Additional discussion of that issue can be directed onto that follow-up Bug 56787 to ensure a clean thread of discussion for it.

Thanks in advance,
Brendan
Comment 157 Michel Moorlag 2017-05-24 09:23:30 UTC Comment hidden (obsolete)
Comment 158 Michel Moorlag 2017-05-24 09:36:57 UTC Comment hidden (obsolete)
Comment 159 abdullah 2017-05-24 09:54:36 UTC
low quality assurance in Xamarin team , and developers getting mad for waiting to this long !!
Comment 160 Neha Kharbade 2017-05-24 10:11:32 UTC Comment hidden (obsolete)
Comment 161 Matt 2017-05-24 15:14:43 UTC
so much rage, I guess no one here has ever missed something... super human developers (applause)
Comment 162 Matt 2017-05-24 15:14:43 UTC
so much rage, I guess no one here has ever missed something... super human developers (applause)
Comment 163 Jimmy 2017-05-24 15:16:32 UTC
*** Bug 56800 has been marked as a duplicate of this bug. ***
Comment 164 Andy 2017-05-24 16:27:56 UTC
No one wants anyone to be super human, or at least that's not what I want. We just want quick access to critical bug fixes. And I think I speak for everyone when I say that removing the ability to modify Xamarin in Visual Studio 2017 was a huge misstep by Microsoft.
Comment 165 Mobigital 2017-05-24 19:02:55 UTC
having the same issue with Android and iOS builds. Is there a way to reduce regression of quality with each Xamarin update? this is super frustrating. 

is there a goal of produced software quality in the team?
Comment 166 Zahi Kramer 2017-05-25 09:48:18 UTC
VS 2017 15.3 brings back the ability to update xamarin seperatly :
https://marketplace.visualstudio.com/items?itemName=Xamarin.XamarinUpdater
Comment 167 lecnier.freeman 2017-05-25 13:18:08 UTC
You can install that extension in 15.2 as well and I remember reading somewhere that depending on VS version they use the stable or preview channels
Comment 168 Andy 2017-05-25 13:45:53 UTC
I've just installed the Xamarin Updater. Whew, glad it's back.
Comment 169 Philipp Sumi 2017-05-25 14:51:50 UTC
@lecnier.freeman: You sure about that? With regards to installing the extension in 15.2, it states explicitly:

  "Make sure you are running Visual Studio 2017 Preview 15.3 or later before installing this extension."

https://marketplace.visualstudio.com/items?itemName=Xamarin.XamarinUpdater
Comment 170 Brendan Zagaeski (Xamarin Support) 2017-05-25 15:09:53 UTC Comment hidden (obsolete)
Comment 171 anton.duzenko@gmail.com 2017-05-25 15:18:48 UTC
I spent most of the last week building and re-building and re-re-building my project because of this. Is anyone in MS actually using Xamarin Forms in practice?
Comment 172 lecnier.freeman 2017-05-25 15:26:35 UTC
@Philipp Sumi: I installed directly in VS 15.2(made only one update so far related to Xamarin.Forms Templates) after reading this:

"The Xamarin Updater detects whether your IDE is a stable or Preview version. It will automatically configure the correct updates for your IDE: only Preview installs of Visual Studio will receive "Preview" updates."

On this link: (last updated: 14 days ago)
 https://developer.xamarin.com/recipes/cross-platform/ide/change_updates_channel/extension-gallery/
Comment 173 Lucian POPESCU 2017-05-25 15:40:54 UTC
I know you guys @ Xamarin are working hard, but I need to know when this is gonna be fixed. Changing its status to RESOLVED FIXED doesn't actually fix it.
I cannot possibly go into the explorer and delete the bin&obj folders before each build. And God forbid multiple PCLs in the same solution.

Thank you.
Comment 174 Lucian POPESCU 2017-05-25 15:50:16 UTC
I'm not even using Xamarin Forms.
Comment 176 Brendan Zagaeski (Xamarin Support) 2017-05-25 21:27:07 UTC
Note that Comment 175 is referring to the installer for Visual Studio 2015 and Visual Studio 2013 that was published to the Xamarin updater channels [1] on May 23 (Comment 145).

[1] See "Change the Updates Channel in Visual Studio 2015 and earlier" on https://developer.xamarin.com/recipes/cross-platform/ide/change_updates_channel/#visualstudio




## Possible temporary automated workaround for Visual Studio 2017

I am in the process of trying a possible automated workaround for Visual Studio 2017 based on the observation from Comment 135 about deleting the .mdb and .pdb files.  I will post back with the results in a few minutes.
Comment 177 Paradise 2017-05-25 21:37:53 UTC
I installed it and after 10 builds , It seems the problem is gone ...
Comment 178 Paradise 2017-05-25 21:39:51 UTC
I'm using VS 2017 ...
Comment 179 Brendan Zagaeski (Xamarin Support) 2017-05-26 02:44:09 UTC
The initial quick workaround idea related to .mdb and .pdb files was unsuccessful, but a different approach did work.

## Temporary workaround for Visual Studio 2017

Use a small custom VS extension to force a garbage collection after the problematic `AndroidSetup::OnBuildBegin()` method but before the build starts.  This is approach is slightly brute force, but it has the desired effect of disposing the unused object that is holding the file handle.


1. Open the Visual Studio Installer and add the "Visual Studio extension development" workload (with the default Optional components).  You can use a Visual Studio 2017 Preview instance for this step to keep the main install cleaner if you like.


2. Create a new "Visual C# > Extensibility > VSIX Project".


3. Right-click the project name in the Solution Explorer and select "Add > New Item...".


4. Select "Visual C# Items > Extensibility > VSPackage > Visual Studio Package".


5. Add `using EnvDTE;` to the usings section of the new file:

using EnvDTE;


6. Add a `[ProvideAutoLoad(UIContextGuids80.SolutionBuilding)]` attribute to the Package subclass in the new file so that the extension will load the first time that a solution starts building.  This should look like:

[ProvideAutoLoad(UIContextGuids80.SolutionBuilding)]
public sealed class VSPackage1 : Package

(Note that the Xamarin extensions load when a Xamarin project is opened, so this new extension will load _after_ that as long as you open a solution that includes a Xamarin.Android project right after starting Visual Studio.)


7. Add the following 2 lines to the end of the `Initialize()` method:

DTE dte = (DTE)GetService(typeof(DTE));
dte.Events.BuildEvents.OnBuildBegin += (s, a) => GC.Collect();


8. Build the project in the Release configuration, and then close Visual Studio.


9. Locate the generated .vsix file in the bin\Release output folder, and double-click it to install it into Visual Studio 2017.




## Results

I tested this approach using the particular local test scenario from Bug 56587, and it stopped the problem completely across multiple trials.




## Additional background info

The call stack that holds open the problematic file handle (see Bug 56587, Comment 6) starts when the IDE OnBuildBegin event [1] fires.  This happens each time the user triggers a Build, Rebuild, or Clean in the IDE.

The `AndroidSetup::OnBuildBegin()` method in particular runs a `GetAssemblyInfo()` method on every assembly that is referenced directly by an Android project.  (The `GetAssemblyInfo()` method only opens assemblies that already exist at the _start_ of the build.  That's why manually deleting the .dll files between builds is effective.)  The recent change in behavior of the Cecil library (https://github.com/mono/cecil) to read the assemblies from disk at this step means that the object must be explicitly disposed to release the file handle, for example by adding `using()` as in https://github.com/mono/mono/commit/5077205a44a7dc97edf6b67072bea53f043cf815.  Forcing a garbage collection is another way to do this.

[1] https://msdn.microsoft.com/library/envdte.buildeventsclass.onbuildbegin.aspx
Comment 180 qaphuiKpoh 2017-05-26 07:15:23 UTC
The temporary workaround fixed it!
Thanks Brendan.
Comment 181 Nuno Mendes 2017-05-26 08:57:09 UTC
Hi,

Can anyone who already created this VSIX for the temporary workaround attach it somewhere so that the rest of us can download it and don't have to add another component (Visual Studio extension development) to the VS installation just for this purpose?

Thanks!
Comment 182 RSUK 2017-05-26 10:05:38 UTC
I have uploaded the temporary workaround .vsix and source that I built using the info in Comment 179 to: https://1drv.ms/u/s!AjNg48gcJCR6o5gY1fC4NP5G3wlMHQ
Comment 183 Nuno Mendes 2017-05-26 10:21:45 UTC
Thank you so much @RSUK!
I've downloaded it and successfully installed it. Rebuilded the solution more than once and it seems to be working! Again, many thanks!
Comment 184 Vladislav Kosev 2017-05-26 10:31:19 UTC
Thank you so @RSUK!
Comment 185 Paradise 2017-05-26 10:34:02 UTC
Thank you @RSUK
Comment 186 y.vinee 2017-05-26 13:14:33 UTC
Thank you @RSUK !
Comment 187 Alex Gavruta 2017-05-26 14:47:34 UTC
Thanks @RSUK!
Comment 188 Heinrich Braasch 2017-05-28 21:36:26 UTC
Working for me too... VS2017. Thanks all
Comment 189 danielferenczi 2017-05-29 08:05:56 UTC
Works for me as well! Thx @RSUK. Still waiting for an official update though..
Comment 190 Lucian POPESCU 2017-05-29 08:06:15 UTC
@RSUK: That VSIX worked from me as well. Thank you so much. Any word on a permanent fix, though?

Lucian
Comment 191 Diego P. 2017-05-29 13:03:23 UTC
@RSUK u r the best
Comment 192 Robert Ros 2017-05-30 07:47:46 UTC
After two weeks of raging, this finally works! Thanks @RSUK!!!

Why is this still an issue in the current version of Xamarin for Visual Studio?
Comment 193 Michel Moorlag 2017-05-30 08:14:03 UTC
For Visual Studio 2015 update 3 it is fixed by installing Xamarin 4.5.0.476. For me at least. For Visual Studio 2017 I do not know. I guess it will come with update 15.3? But Brendan Zagaeski should be able to tell more about the planning.
Comment 194 Michael Rumpler 2017-05-30 08:26:28 UTC
Everybody thanks RSUK for uploading the VSIX, but don't forget Brendan Zagaeski who gave the instructions how to build it.

So thanks Brendan! Your support was outstanding as always. If everybody at Xamarin would deliver such a quality, then we wouldn't have those troubles.
Comment 195 alehlima018 2017-05-30 14:08:06 UTC
Could anyone upload the temporary workaround (comment 182) to a server other than the onedrive? pls
Comment 196 HP 2017-05-30 14:57:32 UTC
The VSIX worked for me. But the text editor syntax coloring for xaml files went away. All is get is code in black n white. I checked options and the color coding for xaml* items are still as default. Any clues?
Comment 197 Brendan Zagaeski (Xamarin Support) 2017-05-30 19:47:35 UTC
## Status update for Visual Studio 2017

The candidate fix for this bug report (from Comment 125) is now included in today's Visual Studio 2017 version 15.2 (26430.12) update (https://www.visualstudio.com/news/releasenotes/vs2017-relnotes
).


(2017-05-30) Visual Studio 2017 version 15.2 (26430.12)

  Includes Xamarin.VisualStudio IDE extension version: 4.5.0.476 (1be4f0c)


If any user still hits a similar behavior consistently after updating to Visual Studio 2017 version 15.2 (26430.12) or higher (or Xamarin.VisualStudio 4.5.0.475 or higher in Visual Studio 2015 and below), please create a new bug report.  Be sure to mention any details for the remaining problematic scenario that might differ from the original scenarios described in this bug report.  Thanks in advance!
Comment 198 Brendan Zagaeski (Xamarin Support) 2017-05-30 20:16:45 UTC
## Status update for Visual Studio 2017 Preview

As an additional status clarification, the candidate fix from Comment 125 is now included in the Visual Studio 2017 version 15.2 (26430.12) from the _release_ channel, but it is not yet included in the current Visual Studio 2017 _Preview_ version 15.3 (26510.00 - Preview) from May 11.  By default it will be included in the next Xamarin update for Visual Studio 2017 Preview.
Comment 199 Robert Ros 2017-05-30 20:34:24 UTC
Michael Rumpler is right: Thanks Brendan! I just updated to VS2017 15.2 and it looks like this issue is fixed! yay!
Comment 200 Philipp Sumi 2017-05-30 21:25:49 UTC
Yay! I'm running into a weird issue with crashes on both iOS and Android in debug mode. VS displays the following message box upon the crash.

Might be this one here:
https://bugzilla.xamarin.com/show_bug.cgi?id=56787


---------------------------
Microsoft Visual Studio
---------------------------
EXCEPTION: Mono.Debugging.Soft.DisconnectedException: The connection with the debugger has been lost. The target application may have exited. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Mono.Posix, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one of its dependencies. The system cannot find the file specified.

   at Mono.Debugging.Soft.SoftDebuggerSession.ResolveSymbolicLink(String path)

   at Mono.Debugging.Soft.SoftDebuggerSession.PathsAreEqual(String p1, String p2)

   at Mono.Debugging.Soft.SoftDebuggerSession.FindLocationByMethod(MethodMirror method, String file, Int32 line, Int32 column, Boolean& insideTypeRange)

   at Mono.Debugging.Soft.SoftDebuggerSession.FindLocationByType(TypeMirror type, String file, Int32 line, Int32 column, Boolean& genericMethod, Boolean& insideTypeRange)

   at Mono.Debugging.Soft.SoftDebuggerSession.ResolveBreakpoints(TypeMirror type)

   at Mono.Debugging.Soft.SoftDebuggerSession.HandleTypeLoadEvents(TypeLoadEvent[] events)

   at Mono.Debugging.Soft.SoftDebuggerSession.HandleEventSet(EventSet es)

   at Mono.Debugging.Soft.SoftDebuggerSession.EventHandler()

   --- End of inner exception stack trace ---
---------------------------
OK   
---------------------------
Comment 201 Philipp Sumi 2017-05-30 21:30:22 UTC
Ok, that seems to be yet another bug:
https://bugzilla.xamarin.com/show_bug.cgi?id=56787
Comment 202 MG 2017-05-30 22:26:17 UTC
Still can't have breakpoints for iOS (Debugger won't hit them), is there any known bugs similar to my case?
Comment 203 Heinrich Braasch 2017-05-30 23:54:04 UTC
Back on VS 2017  (15.2 26430.6 with this workaround), I could also not hit breakpoints for iOS, but used the (hopefully temporary) workaround to get it working again: Set iOS Build=> Linker Behavior to <<Don't Link>>. No idea why this works, got the idea from another discussion.
Comment 204 Reader Man 2017-05-31 05:30:18 UTC
I began having this issue suddenly in VS 2017 u2, then switched to VS 2017 u3 preview, and the error did not happen but after several days, it began coming, and restarting VS 2017 u3 preview, will stop it from appearing, but after several builds, it returns, and again i need to restart it, but when i installed the .vsix thanks to @RSUK, it stopped at both VS 2017 u2 & u3.

Shortly i finished my project, so i don't know if i continued for long time it will return or not, but i am afraid that even when VS 2017 u3, comes to release, this error will return, so please, this a show stopper.

this is the build output from VS 2017 u3 preview:
https://goo.gl/sgGKF8


Regards.
Comment 205 Brendan Zagaeski (Xamarin Support) 2017-05-31 17:29:12 UTC
Please see Comment 197 and Comment 198 about the release locations of the fix for this particular bug report.  In particular, please note that the most recent Visual Studio 2017 _Preview_ release is dated May 11 [1], which is before the candidate fix for this issue in Comment 125.

[1] https://www.visualstudio.com/en-us/news/releasenotes/vs2017-preview-relnotes


This exact bug report can be considered closed at this time.

If any user still hits a similar behavior consistently after updating to Visual Studio 2017 version 15.2 (26430.12) from May 30 or newer (or Xamarin.VisualStudio 4.5.0.475 or newer in Visual Studio 2015 and below), please create a new bug report.  Be sure to mention any details for the remaining problematic scenario that might differ from the original scenarios described in this bug report.  Thanks in advance!
Comment 206 Brendan Zagaeski (Xamarin Support) 2017-05-31 22:45:26 UTC
*** Bug 56917 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.