I'm facing this error after updating Xamarin to the latest version today (12-2-2014) and there is no solution except closing and opening VS each time I want to run the app and this is unbearable !

Error 447 The last access/last write time on file "bin\Debug\appName.dll.mdb" cannot be set. The process cannot access the file 'C:\Users\ahmedkamal\Source\appName\bin\Debug\appName.dll.mdb' because it is being used by another process

For some reason my build process start working again.
The following are the steps I did:
1. After installing the notified update (which is for Xamarin.iOS so it should be unrelated to this issue).
2. I opened visual studio and run my android app. App runs at this point, then stop debugging.
3. Then I decided to run Xamarin Studio and open my solution.
4. I run the android app from XS and I got the "The process cannot..." error, because my visual studio still running.
5. I closed VS.
6. Run the android app again in XS and at this time the app runs.
7. Stopped debugging and run again and the app still runs plus I don't get the "The process cannot..." error anymore.
8. So I opened again VS and run my android app couple of times, since then I don't get the "The process cannot..." error anymore.

I am confirming that latest Tomas recipe solved me this issue too. Many thanks!
Additionally, I compared the files after opening solution in XamarinStudio - most important thing is probably that XS removed my AndroidUseSharedRuntime="true" tag from "*.Droid.csproj", but it also replaced VS2013 to VS2012 in SLN as default (I have both now; when you change here back to "# Visual Studio 2013" it stays here then). By adding *.userprefs to git/svn ignore, it seems we have fully two-way solution for VS2013 and XS, which also changes in some *.csproj "Project ToolsVersion="12.0" to "4.0" but VS doesnt complain - consequences??
( Truth is, that bin\debug*.dll.mdb is still present after "Clean" in XS or VS )

I've taken a look with Process Explorer, and the mdb file is indeed still open in devenv.exe. If I close the handle in Process Explorer, I can build just fine (one time). Since I didn't install any updates to Visual Studio, the problem must be in Xamarin.Android.

Same error here and it is VERY VERY annoying.
I am wasting a lot of time restarting every time VS and this is not acceptable for all those people that are actually paying a lot of money. We need at least a workaround as soon as possible because the business does not wait.

Here is a small console application I wrote that I then added to my pre-build events for my android application that calls handle to "cleanup" the issue anytime I try and debug. You just need to pass the name of the mdb as a argument AND have the handle.exe in the same directory as this executable. NOTE: I wrote this in about 5 minutes so I do not guarantee the results... run at your own risk.

Has anyone heard from Xamarin regarding a "REAL" fix for this issue? It has come and gone for me for months now. And it is back. I am running 3.11.590. It is locking the .dlll for my PCL in a Xamarin.Forms project. I have to shut VS down and re-open every time. This is unacceptable for a product which costs as much as Xamarin does.

I work with 3.11.586 and don't have this problem (but still various other and one more "evergreen" -> VS hangs, when a resource is added in Android -> therefore a workaround is described in my thread).

So.. I suggest you to downgrade, if possible and you can live with problems to .586 (see my thread).

I think, the most of us have gave up to post the problems to the "official threads" (as it - unfortunately - seems to do not help).
Nevertheless you should post a short message to the "official thread" to your version (if only to prevent other users, to do the update )

As I wrote in my posting, I don't had this problem with 3.11.586.
Before a while, I had to update to 3.11.836.0 (to prepare - hopefully - my iOS app for the iOS 9 Update).
The new version for the iOS-App is uploaded for Apple review already.Now, I want to update also my Android app and... yes.. the evergreen is back!
If I try to Publish the Android app (Release configuration), I can't as some DLL's (I can see Json.dll) are "in use by another process"...
Close VS and restart don't help...

Just annnoyinggg!

Have you found a workaround in the meantime...?

Or can somebody say, that he don't have the problem in the latest 3.11.894 ?
=> I can't see that it should be re-solved in the release notes...

Unable to copy file
"E:\MyApp\packages\Xamarin.Forms.1.5.0.6447\lib\MonoAndroid10\Xamarin.Forms.Core.dll"
to "bin\Debug\Xamarin.Forms.Core.dll".
The process cannot access the file
'bin\Debug\Xamarin.Forms.Core.dll'
because it is being used by another process.

Yet another day completed wasted by Xamarin not testing their stuff properly before putting on the stable channel. I'd far rather they sorted out their quality and release processes rather than make the big fanfare about 0 day support for new stuff. I REALLY don't care about 0 day support. I want a predictable, reliable system to work on.

I am just hoping that iOS is working, because right now, everything else is completely stuffed. Keeping fingers crossed for iOS, but as I was doing the upgrade in the hope of fixing an existing Xamarin iOS problem that prevented me working on iOS, I really don't hold out much hope.

[Note added later: It didn't matter how many times I cleaned the solution/project, this kept on happening. Re-starting VS and re-starting the box didn't resolve it either. However, going in manually and deleting the bin directory seems to have worked. I have re-built a few times since without issue. Still not happy though at having to waste time on stuff like this]

I encountered this problem today on the iOS project of a xamarin.forms
solution.

The file myProject/myProject.iOS/bin/iPhone/Debug/somePcl.dll was not released,
so subsequent builds failed because the file couldn't be copied there.

After shutting down VS and deleting the file I was only able build one time.

A longer-lasting solution for me was to MOVE the file to a different Folder.
The moved file remained unreleased, but copying to the original folder worked
now, so building succeeded - and more than once.

Happened to me too, just building a stupid C# console app to aid in testing. (Did I mention it's about impossible to debug unittests?) Couldn't even delete the executable after a reboot. Required a program called Unlocker to be able break the little mofo's deathgrip on the system, and it still requires a reboot to finish the job. Not cool. v5.10.1, Windows 10