Related
I suddenly have begun encountering an error similar to "E:\Websites\Stage\mywebsite\somefile.ascx: Access to the path is denied" on a multitude of my local files when attempting to check them in. The files it is failing on are all sorts of files, PNG, ASPX, CONFIG, etc.
I am using Visual Studio 2013 for Web (Update 4) and the visualstudioonline.com TFS.
The files are stored on a network location and I have a drive mapped to that location. I can manually open, manipulate, and save any of the files that error so I do not believe it is truly a permissions issues.
This setup has worked for months but suddenly it is giving me problems.
I ran a powershell script on the folder Get-ChildItem -Include *.* -Recurse -Path 'E:\Websites\Stage' | select fullname,isreadonly and all the files return 'False' under the isreadonly column. No errors are returned.
I am in need of some further ideas.
I found a workaround in another StackOverflow question.
Essentially, you shelve the pending changes, then you commit it. No need to unshelve them.
I would only suggest to use that to check-in your changes until you set another workspace locally (or someone fixes that issue).
As many other, using Visual Studio 2013 from within a VM having a local workspace located on the host computer mapped through a shared drive was working well before updating to "VS2013 update 4".
That setup was suggested to me with the reasoning that if the VM crashes, then I wouldn't loose my changes.
Storing your local workspace on a network location is not supported and should never be done.
Have a 'local' (physically on your local machine) workspace where you edit the files and check in. Then have an automated build that publishes the files to a location of your choice.
I ran Windows/Visual Studio in Parallels on a Mac and had a project saved to my desktop (yes, shame on me). Internally this path is handled as \\psf\Home\Desktop even if it is stored locally and not in the network. Still gives the same exception and is solved by moving it to your regular drive (c:\...)
I have been trying to publish my service to windows azure. The service consists of a single webRole, however I have added remote login functionality published it and built it a few times, and now all the sudden it will not build. The reason it gives is that
Details below:
"Error 56 The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets 202 5 FileSystemCreator"
I have gone on all the forums, I have used CSPack command line for packaging the service which is fine but I'm having a really hard time configuring the certificate for remote desktop connect and I would like to take advantage of this feature as I am creating some websites in the onStart event and I would like to peek into IIS. Some microsoft employees do agree that this is a bug and the have promised a fix this issue, refer to post . I am using VS2010 and I do not know how to fix this bug.
Can anyone please help, or point me to a place where I can get any help.
I ran into the same problem with a new solution.
Note that, unlike Eugenio Pace's response suggests, the error occurs only when deploying to Azure (and not when running the project in the Azure Compute Emulator).
Try adding the following line to the first property group of your Windows Azure Visual Studio Project file (*.ccproj):
<ServiceOutputDirectory>C:\Azure\</ServiceOutputDirectory>
The trailing slash (for whatever path you select) appears to be required. This folder will be deleted each time you create a package if it exists.
This setting seems to redirect the working folder for the package to a shorter base path, preventing the path too long error.
Credit goes to: http://govada.blogspot.com/2011/12/windows-azure-package-build-error.html
Perhaps the local folder used to store temporary development fabric is too long. See Windows Azure - Resolving "The Path is too long after being fully qualified" Error Message.
I was having this problem as well when deploying a Node.js project to Azure.
To fix it, I had to change my "TEMP" and "TMP" user environment variables to something shorter than their default values.
In my case, they were pointing by default to %USERPROFILE%\AppData\Local\Temp, changing them to C:\Temp solved it.
Make sure you restart Windows after.
The better solution may be to create a symbolic link to your project folder. This doesn't require moving files or changing system variables. Open up the command prompt as an administrator and run this:
mklink /D C:\Dev C:\Users\danzo\Source\Workspaces
Obviously you can change "C:\Dev" to whatever you want it to be and you'll need to change the longer path above to the root directory of your soltions/projects folder.
Same problem happened to me when I try Packaging an Umbraco project for Azure (https://github.com/WindowsAzure-Accelerators/wa-accelerator-umbraco/wiki/Deployment), I found the solution is to: Copy and rename the long-name path and folder to "C:\someshortname".
(solution was suggested by this: link)
I tried all the above 2 approaches:
-change TEMP and TMP enviromental variables
-<ServiceOutputDirectory> path
and didn't work.
In my case, I had to move the whole project to a shorter path C:\ and worked.
I'm using W7 and VS12.
When you run a cloud service on the development fabric, the development fabric uses a temporary folder to store a number of files including local storage locations, cached binaries, configuration, diagnostics information and cached compiled web site content.
By default this location is: C:\Users\\AppData\Local\dftmp
Credit goes to Jim Nakashima of Microsoft :
https://blogs.msdn.microsoft.com/jnak/2010/01/14/windows-azure-resolving-the-path-is-too-long-after-being-fully-qualified-error-message/
In order to change the temporary folder, a user environment variable has to be created :
It is named _CSRUN_STATE_DIRECTORY
Give it a value of short named directory like :
c:\AzureTemp
Don't forget to restart Visual Studio in order to have the environmennt variables to be read again
It fixed many compilations problem !
SourceSafe Related Error message I got in Visual Studio 2010 when I tried to edit a file:
File is already checked out by the current user in a different location
Background:
For some reason source safe saved the files 3 directories deep.
For Example, The solution files were located in: VS2010Apps\CCP_Utility\CCP_Utility\CCP_Utility\
The solution files should be in the root directory: VS2010Apps\CCP_Utility
I moved the files to VS2010Apps\CCP_Utility to create this error and now I can't edit my project....
Question:
How can I edit my files again and keep the correct directory structure???
Do I Just delete the source safe files and re-add it to source safe or what?
It sounds like VSS is expecting those files in a particular directory. To solve this:
find and make the path that VSS is expecting; the one with ccp_utility x 3.
check-in (all files) to VSS.
if you don't care about version history at this point, delete the project from VSS.
disconnect/unbind your solution from version control.
make the directory layout on disk as you need.
drag & drop the root folder of your new layout on disk into VSS Explorer. Suggest make it a brand new path (aside your old project) in VSS, to avoid any complications.
you now have a 'new project' as far as VSS is concerned.
ensure your bindings are correct, and you should be able to continue as per normal.
This happened to me when my work machine was replaced and I had forgotten to check in some files on my old machine before the change. My local copy of the file was the one I wanted to work with, but VSS had it marked as checked out on a different machine [my old machine].
I just opened the Source Safe Client, browsed to the affected files and checked them in: the client asks if I wish to proceed using the local file (Yes) - then just reloaded the project in Visual Studio.
I'm unable to debug a WinForms C# application using the released version of Visual Studio 2010 Prof.
I get the following error message after the second debugging run.
Error 9 Unable to copy file "obj\x86\Debug\Arrowgrass Reports.exe" to "bin\Debug\Arrowgrass Reports.exe". The process cannot access the file 'bin\Debug\Arrowgrass Reports.exe' because it is being used by another process.
I've tried a pre-build script to attempt to delete this file, but it's locked by Visual Studio.
There are a few references to this on the net so it is a know problem. Does anyone have a hotfix or effective work-around?
I have found this issue very easy to reproduce, and the fix for me is a variation on Richard Fors' answer. If I have a UserControl open in the designer, run the debugger, and then edit the UserControl, the subsequent rebuild will fail. If I close the UserControl before running the debugger I never get this error, so I just make sure to close the designer window before hitting F5.
As of October 2012, I still have that issue so the VS 2010 SP1 didn't solve the problem. What I did, and worked consistently, was disabling the hosting process in the projects.
To disable the hosting process:
. Open a project in Visual Studio.
. On the Project menu, click Properties.
. Click the Debug tab.
. Clear the Enable the Visual Studio hosting process check box.
Source:
http://msdn.microsoft.com/en-us/library/ms185330(v=vs.100).aspx
You can try to kill the vshost.exe process:
taskkill /F /IM "Arrowgrass Reports.vshosts.exe"
You might also be lucky and simply be able to move the file in question. Moving the file can be done by adding the following lines of code to the pre-build event of your project:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Disabling windows search did not fix for me. However disabling Antivirus did (our Antivirus is Symantec Endpoint Protection 11)
As such, I was able to fix this for myself by changing the Debug settings in the project to point the working folder to a path on the C: drive, and then excepting that path from the antivirus auto-protect scan settings.
I hope this helps someone.
I posted this answer in a similar question but figured I'd also say it here:
Alright... this might sound pretty crazy.
I've had this problem in VS2010 for the last couple of years. The workaround mentioned here works for me, but a lot of times I forgot to close all my forms/usercontrols first.
I've discovered that merely going to view the open files via:
Computer Management (compmgmt.msc)->Shared Folders->Open Files
will "Free up" whichever file is being locked. Very strange, but it works for me!
In my case, I did Project Properties-->Security Tab-->Uncheck Click-Once security settings (If it is checked). It worked for me. In my project, it was showing this error for a C++ dll being used in my C# project.
The condition described can also be caused by the offending DLL or EXE referencing itself; in which case the Process Explorer test described previously never returns a match (e.g. it's not running). This unexpected situation seems to be caused during some sequence of operations in VS2010 (and likely all previous versions) which insidiously adds the reference behind the scenes. The specific cause of this hasn't been tracked down (or resolved that I know of). To check for, and resolve this error simply make sure the offending DLL or EXE is not listed as a reference to itself.
Got the error ("The process cannot access the file … because it is being used by another process") when I modified the (Visual Studio 2010 C# Express with SP1) solution from two large (10 source files, ~500 lines per file) projects with one referencing the other, to lots (6) of smaller projects with lots of projects referencing other projects.
The references were to the dll- and exe files (the Debug versions of them), NOT to the projects even though the projects were in the same solution.
I then learned that references should be to projects, not files, for F12 to work properly. So I modified the references. That made F12 work (jump to the source file instead of some auto-generated interface description), and at the same time the "cannot access file" error during build disappeared.
I only got the "cannot access file" error when doing Release builds. The references were to the Debug versions of exe/dll's. I suspect that this mixing is what triggers the bug in VS.
I encountered this issue when developing windows services. I found out that it happens when the service is running. Thus, you only need to stop the service (from the services.msc console) and you're good to go !
Hope this helps.
Tidjani.
Check Task Manager for the specified process and End the process explicitly. This solution worked for me.
I cant' write to a comment since not at 50 points but for me I excluded my project folder in ESET Enpoint Security ver 5. Seems like it blocked/hogged some files. My Error did not state which exe or file was in use so it took a long time to finally get to what JoeC said about Antivirus and tried it. Seems to be working now (Visual Studio 2010 SP1)
Closing recently changed User Controls solved the problem in my scenario. Hope this will help somebody out there.
Looks like this issue has (finally!) been fixed in the VS2010 SP1
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=75568aa6-8107-475d-948a-ef22627e57a5&displaylang=en
Please try uninstalling Windows Live SYNC. Does it still happen?
I think I just found the culprit and the solution.
Go to services and stop & disable the "windows search" service.
That solved the problem for me now.
For me the solution was to change the startup project to a dll (problem only occurs in debug mode when having an application as the startup project). If your solution contains several projects (and it will, and it will contain a .dll, else you would not get the problem), switch to that .dll, no .vshost.exe, no problem.
Also, killing .vshost.exe did not work for me, since immediately after starting again, it had locked the .dll.
Also, make sure to have your references clean, especially in more complex projects, and also prefer project references to assembly references, and so on. I suppose bad references (circular and similar) are bound to cause problems, at least so I have read.
A short article by me on this problem (and my solution)
How to "clean up" your references in a solution
Adding the following to the Pre-build event of the shared dll worked for me:
if exist "$(TargetPath).locked*" del "$(TargetPath).locked*"
set exitprebuildfor$(ProjectName)=
for /l %%a in (1,1,10) do (
if defined exitprebuildfor$(ProjectName) goto :ok
if not exist "$(TargetPath).locked%%a" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked%%a" & set exitprebuildfor$(ProjectName)=1)
:ok
set exitprebuildfor$(ProjectName)=
It's based on the solution given here but instead of just renaming the dll to .locked it keeps trying to rename it to .locked1, locked2. Using 10 I usually run into the problem once a day, but ant value can be used.
Simply make a copy of the whole project and run project from the new copy.... it will work fine.
But you will have to end process of the debug somehow in-order to delete the older project.
Stop IIS service and try building it again or if you can afford to restart your pc, give it a try. Worked for me both ways.
Cheers
My problem was that Outlook 2010 (outlook.exe) was using the same port as my ASP.NET MVC project with IIS express.
Solution: close outlook.exe, run your solution and open outlook again (so that it uses another port).
Hopefully this helps somebody, because I received the same error message as described in this topic.
Try deleting .exe file in debug or release folder (whatever you working on)
Windows will prompt that the process X has opened this and you can't delete it
after that go to task manager and in details tab end task X process
Delete obj file.And stop your service and Restart again.Then you may solve the problem
The best solution for me was to move my project files out of My Documents - which is on a server managed by the IT department - and locate them locally on my C drive. Also working: unchecking the "Enable the Visual Studio hosting process" checkbox, as stated by other people.
If you are working on a C# project which is using reference of C DLL, then you can eliminate the error by checking the Allow unsafe code check box. I know I have not used pointers in my C# project but I was using some bitwise operator in C#. May be these C-like features morphed it as 'Unsafe' code.
What worked for me was removing "read only" status on the bin folder. Once I did that, it has worked ever since.
I've had this error when the project is on a remote share (like, if your $env:homepath is helpfully redirected by your IT department to a network share). Make sure your project is resident on a local drive.
My problem started after creating a custom control and drag and drop it to the toolbox palette for use it in design forms. First appeared a warning saying that there was a redundance between the custom control source file (.cs) and the projects executable (.exe). On executing/debugging appeared the error: unable to access the (.exe) because it's being used (and it was true).
A literally removed the whole source code regarding the custom control and last problem never stopped, until I checked out the references and it was referencing itself in order to be "able to" get the former custom control. I removed the reference and done!!
So: just check the references and remove the self-reference to the project.
Delete your Bin folder and run the application.
This worked for me. :)
Simply turn off Visual Studio hosting in debug, run the project and again re on it and run project.
Open a project in Visual Studio.
. On the Project menu, click Properties.
. Click the Debug tab.
. Clear the Enable the Visual Studio hosting process check box
For Windows Project
The Visual Studio hosting process can hold the executable file pointer. To stop the host instance, open the Project properties and then go to Debug tab. Now uncheck the Enable the Visual Studio hosting Process option and then check the checkbox again to debug.
For web project
The IIS can hold the file pointer. Restarting the IIS can solve the issue.
For one of my ASP.NET 3.5 applications, every single time I try to build the web app, it throws the following build errors in Visual Studio 2008:
Error 165 Unable to copy file "C:\InOne\Common\DexProcessor\bin\Debug\DexProcessor.dll" to "bin\DexProcessor.dll". The process cannot access the file 'bin\DexProcessor.dll' because it is being used by another process. InVision2
Error 166 Unable to copy file "C:\InOne\Common\DexParser\bin\Debug\InOne.DexParser.dll" to "bin\InOne.DexParser.dll". The process cannot access the file 'bin\InOne.DexParser.dll' because it is being used by another process. InVision2
Error 167 Unable to copy file "C:\InOne\Common\AlertProcessor\bin\Debug\InOne.Invision.AlertProcessing.dll" to "bin\InOne.Invision.AlertProcessing.dll". The process cannot access the file 'bin\InOne.Invision.AlertProcessing.dll' because it is being used by another process. InVision2
Error 168 Unable to copy file "C:\InOne\Common\InVision.BusinessLogic\bin\Debug\InVision.BusinessLogic.dll" to "bin\InVision.BusinessLogic.dll". The process cannot access the file 'bin\InVision.BusinessLogic.dll' because it is being used by another process. InVision2
Error 169 Unable to copy file "C:\InOne\Common\InVision.Common\bin\Debug\InVision.Common.dll" to "bin\InVision.Common.dll". The process cannot access the file 'bin\InVision.Common.dll' because it is being used by another process. InVision2
Error 170 Unable to copy file "C:\InOne\Data\bin\Debug\InVision.Data.dll" to "bin\InVision.Data.dll". The process cannot access the file 'bin\InVision.Data.dll' because it is being used by another process. InVision2
Error 171 Unable to copy file "C:\InOne\Common\InVision.DataAccessLayer\bin\Debug\InVision.DataAccessLayer.dll" to "bin\InVision.DataAccessLayer.dll". The process cannot access the file 'bin\InVision.DataAccessLayer.dll' because it is being used by another process. InVision2
Error 172 Unable to copy file "C:\InOne\Common\InVision.DataAccessLayer.SqlClient\bin\Debug\InVision.DataAccessLayer.SqlClient.dll" to "bin\InVision.DataAccessLayer.SqlClient.dll". The process cannot access the file 'bin\InVision.DataAccessLayer.SqlClient.dll' because it is being used by another process. InVision2
This just started happening a week ago and is very annoying... I have to go into the web app's bin folder and delete the pdb files and then it'll let me delete the dll's most of the time. Every once in a while it doesn't let me so I have to close Visual Studio and then it lets me delete them. I checked and it's Visual Studio (devenv) that is locking the dll's. Rebooting the machine doesn't help.
This is really reducing my productivity, is there anything I can do to resolve this?
As mentioned, Visual Studio 2008 (devenv.exe) is the process locking the DLLs.
I noticed something... When it compiles successfully, it's copying all the DLLs into the bin folder, then they are all deleted, then a new set are copied into the bin. When it isn't successfull, the first set of DLLs are copied in, then it fails. So it seems to be using the bin folder for 2 things when it should only be for 1. Does this help??
The issue ended up being that in the web.config someone had added:
hostingEnvironment shadowCopyBinAssemblies="false"
After commenting this out, everything started building ok. What a nightmare!!
Use ProcessExplorer to find out what process has the file open and go from there.
If a process is currently using those DLL, you can't delete and re-write it. You'll have to kill or otherwise stop the process using those DLLs while you compile.
I have battled this issue FOR YEARS!
Have you tried adding this to your PREBUILD Event?
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
See this for more info:
http://nayyeri.net/file-lock-issue-in-visual-studio-when-building-a-project
Here's another thread, with more things to try...
http://social.msdn.microsoft.com/forums/en-US/Vsexpressinstall/thread/5b71eb06-5047-483d-8fd3-b75c102d41e9/?prof=required
What worked for me is the following pre-build event:
if exist "$(TargetPath).locked.bak" del "$(TargetPath).locked.bak"
if exist "$(TargetPath).bak" del "$(TargetPath).bak"
if exist "$(TargetPath).locked" ren "$(TargetPath).locked" "$(TargetFileName).locked.bak"
if exist "$(TargetPath)" ren "$(TargetPath)" "$(TargetFileName).bak"
What I have noticed in my case is that the 2 files are being created and can not be deleted. You can, however, rename them (and they are still in use if you try to delete them). On a next build, the renamed files are no longer in use (lock removed) and they can be deleted, which is what the above script does, after which it can safely rename the new locked files so there will be no problems in generating the build output.
The other pre-build events posted here and in other places did not help me a lot (they worked only for one extra build or only a few before the problem arose again). So now I am currently using the one posted above for my debugging purposes.
I just wanted to say that this problem started with me today. (VS 2010, C#) I have been working on this program for a month without this problem, now today it started. I start VS, change code, compile and test and quit program. Make another change, compile and BOOM Unable to copy file "obj\x86\Debug\progname.exe" to "bin\Debug\progname.exe" because if is being used by another process.
ProcExp shows only Visual Studio (actually devenv.exe) using this file. There is only one instance of VS running. There are two listing on my debug\progname.exe, one is a Type DLL, the other is a Type handle.
Using devenv /ResetSettings did not resolve anything, but wasted 10 minutes putting everything back to my desired view.
Using the PREBUILD events rename trick mentioned above solves the problem for a couple of changes, but on the next change the "exe.locked" file is locked and cannot be deleted. Then the rename fails.
The debug\progname.exe file name remains locked even after closing the project.
Closing VS, manually delete the files in the debug folder, opening VS and my solution, then Build->Clean Solution seems to work for me, at least its working now after I did all of that stuff.
Hope this helps
-rwg
I didn't have any luck with the pre-build events unfortunately. What worked, in typical IT Crowd fashion, was to quit Visual Studio and reopen it.
Easy fix for Windows 7:
Start the service "Application Experience" . Search for "Services" in "Control Panel".
-Martin
If you have Visual Nunit, it must be locking dll file.
Close VS
Go to taks manager , kill the Visual Nunit process
Now open VS and build the project
Hi I'm facing the same issue for a little while. It's very annoying.
I have an easier yet not so efficient solution for the problem.
Cleaning the project or solution solves the problem.
Just go to \Debug\bin and delete all .dll files.
Working great for me.
I had this issue on a web project with System.Web.Extensions.dll from the Microsoft Reference Assemblies folder. Setting "Copy Local" to false in the reference properties fixed it.
You could download the excellent SysInternals Handle program. This will tell you which processes have a lock on the files concerned.
If it is an external program (e.g. virus scanner/indexer) then this should help. If it just reports Visual Studio (devenv.exe) as the culprit, then it will be of less help!
I'm assuming you already know it's VS2008 which is locking the files. You can try running MSBuild from the command line and see if the problems disappear. Unfortunately Visual Studio can keep files locked when it shouldn't, in some hard-to-predict scenarios.
File locks are just part of working with Visual Studio. There aren't any great ways to get around this problem.
There was a specific bug in Visual Studio 2008 which was fixed in SP1 which may be your issue. It occurs when you reference an embedded JavaScript file and causes the problem you are seeing. See here for more details.
I did had simillar problem
solution for me was to look at the *.csproj file and under i found missing file so and below was correct one so i just removed lines and it worked straight away
Removing the following lines from my app.config solved this for me - I'm using VS2010.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="nunit.framework" publicKeyToken="96D09A1EB7F44A77" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-2.5.7.10213" newVersion="2.5.7.10213"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
Check if the user dll and the application referencing the dll target the same .NET framework.
I had a case where the frameworks were different which caused this problem.
This happens to me sometimes when using Visual Nunit for unit tests.
It seems the process 'VisualNunitRunner.exe' locks the .dll files in the destination directory.
I used Unlocker to find the process, kill it or unlock the files.
I had similar issue and was able to resolve it by changing the 'AssemblyInfo.cs'
Visual Studio build fails: unable to copy exe-file from obj\debug to bin\debug
The file cannot be deleted, fortunately can be renamed and moved. So I created prebuild batch (using date and time as random string, there can be easier ways):
For /f "Tokens=2,3,4 Delims=/. " %%i In ("%Date%") Do #(
Set Month=%%i& Set Day=%%j& Set Year=%%k
)
set ActDate=%Year%-%Month%-%Day%
For /f "Tokens=1,2,3 Delims=/.:, " %%i In ("%Time%") Do #(
Set Hour=0%%i& Set Min=%%j& Set Sec=%%k
)
set ActTime=%Hour:~-2,2%-%Min%-%Sec%
move c:\MyProject\bin\Debug\myproject.exe c:\garbage\%ActDate%_%ActTime%_myproject.exe
Happened to me just now. Had to kill all devenv.exe processes (there were 3 of them after closing VS 2010 window).
Delete the binaries from the bin\Debug folder and recompile them. This works for me!!!
This issue commonly occurs when you change your project from one directory to another . For the Shadow copy error you might have added this line in your web.config.To fix this follow the following
In your web.config file if there is something like
<hostingEnvironment shadowCopyBinAssemblies="false" />
change that into
<hostingEnvironment shadowCopyBinAssemblies="true" />
or remove it .Then it will work fine
I was using Visual Studio 2012 when this started happening on a 7 year old solution (for the second or third time: I've been to this question before).
I tried the various voodoo. I cleaned the solution. Didn't work. I restarted Visual Studio. Didn't work. I was confident that last one would work, because that is the voodoo that worked last time.
Ultimately, I remembered a security update had installed last night and was configured when I started my machine this morning - (Connected or not? No Idea) - So, I restarted Windows, and voila, it all worked like magic again.
Thanks MS for more mind mincing.
I also face this problem. First i try to delete contentious .dll but it shows Access denied, then i close my VS and after open, it works fine.
Similar to Benoit's answer but doesn't require any tool installation, you can use tasklist (task manager) command at the command line with the '/m' switch to get a list of processes using the dll:
tasklist /m mylocked.dll
I saw some posts indicating you have to do it from the directory of the offending dll, but I haven't found that to be the case.
you can also delete bin and obj folders in all projects in solution then rebuild solution.
open your project in explorer click the property of the bin folder and uncheck the read only property this one works in my xamarin forms project
I finally how fix it. It Occures because the first debug exe still running. So , go to Task Manager -> Process Tab -> [your project name exe] end the exe process