Today, while trying to publish an app so I could test it, I suddenly got this error message:
The item
D:\ScratchSrc\TryNewReportViewer2017\TryNewReportViewer2017\TryNewReportViewer2017.csproj.vspscc
could not be found in your workspace, or you do not have permission to
access it.
That's a mystery to me, as I've never gotten this before and I was working with this app just last week. Publishing it, too.
I've looked for the .vspscc file. Found it exactly where it said it should be. So, the alternative is that I don't have permissions to it. I don't understand why I shouldn't have permissions to a file on my machine that I created, but whatever. So, how do I get permissions to my own file?
I'm working with VS 2017, TFS 2015 on premise.
This issue may due to the wrong source control binding for that specific xx.vspscc file.
Double check your source control bindings for that file in TFS. You could also try to unbind and rebind the file.
Then delete the file in local(back up local changes first) and get latest version from TFS. Finally do the publish again.
If above solution is still not working, try to delete local workspace and create a new one, get latest version of the file, modify the file with local changes (if you have) in your backup , check in the file, then do the publish .
Another reason for this problem is, that the vspscc file is not checked in.
Just do a "Compare" on the project folder to see, if it's missing.
If the csproj.vspscc is missing you can create a new one by removing the project in visual studio and adding it back
I was able to 'fix' the problem by going to the source control explorer, selecting the smproj file (which was checked out for editing), and checked it in by itself. Then, I checked in the Model.bim. Was able to do both of these things without getting the error.
I also tried all the usual things, deleting the entire solution directory, getting it from TFS again but nothing worked.
Noticed the version of Visual Studio 2019 was a few months old so upgraded to the latest. That fixed it!
Am trying to publish my Web Application. It worked fine literally 15 minutes ago and not aware of anything changing in the meantime. Now receiving this error:
Copying file bin\myApp.dll to obj\Release\Package\PackageTmp\bin\myApp.dll failed. Could not find a part of the path 'obj\Release\Package\PackageTmp\bin\myApp.dll'.
Tried copying the dll manually and Windows just hangs.
Any ideas?
Usually this happens to me when a file is locked (still in use) by windows.
Try right clicking on the solution and doing "clean" solution. Then rebuilding.
If that does not work. Try cleaning solution, closing Visual Studio, re-opening it, then publishing it.
Think I've fixed it. Had to remote directly into the server and cut the release folder to the desktop then copy it back again. Window's threw some permission errors, which it shouldn't have as I have full permissions but worked when I clicked "Try Again". Then manually inserted the dll the same way and tried publishing again. This time it worked. Bit of a weird one but seems to be working now.
I was looking for a solution to this problem and I've found out, in my case, that the folder was not being created when the project was published in IIS. So I've copied the folder from my project's directory to the location where the project is published.
It worked for me!
I had a similar issue and found that the cause was the permission set in the Build folder located in the project folder where the software is compiled to.
For some reason the permission were not set to full, and on further investigation the delete permissions were not set to active.
This meant that the first compile succeeded, but the second failed because the original folder could not be cleared by Visual Studio, or the original files could not be overwritten.
Setting the permissions to full fixed this issue.
This happened to me when you have a files that the path that is longer than 255 chars.
Ensuring all file paths from the drive root to all the files in the Debug\Package\PackageTmp folder were shorter than 255 corrected the issue for me
I have several programs that I have created in vb.net visual studios 2010. I have been working on these programs for months with no problems. Recently I started having an issue where I can no longer access my temp directory while debugging within VS. I can't use My.Settings anymore because these use those temp files. This is the error I get:
Failed to save settings: An error occurred loading a configuration file: Could not find a part of the path 'C:\Users\USERNAME\AppData\Local\PROGNAME\PROGNAME.exe_Url_gty0snnfox5ji5xgprklljwb0e0mthek\1.0.0.0\nl3u0fw2.tmp'. (C:\Users\USERNAME\AppData\Local\PROGNAME\PROGNAME.exe_Url_gty0snnfox5ji5xgprklljwb0e0mthek\1.0.0.0\user.config)*
This file is there though.
I also get an error when trying to use my web services. I get this error:
Access to the temp directory is denied. Identity 'DOMAIN\Username' under which XmlSerializer is running does not have sufficient permission to access the temp directory. CodeDom will use the user account the process is using to do the compilation, so if the user doesn�t have access to system temp directory, you will not be able to compile. Use Path.GetTempPath() API to find out the temp directory location.*
I used the Path.GetTempPath() as the error says and I am trying to access: >"C:\Users\USERNAME\AppData\Local\Temp\"
I have tried going to these folders and making sure that I have the security set to allow everyone complete control. I believe it is a problem with VS not my program because I get the same problem on all of my programs, some of which I haven't opened in months. I did a repair on VS.
I can't think of what might have changed to cause this to stop working all of a sudden. I traveled to a customers facility where I had to change some network settings, but everything should be set back as it was now. My temporary security certificate expired, but I created a new one and now the certificate I am using to sign these applications is in my trusted root on certificate manager and looks to be valid. I should also mention that this is a clickonce deployment and the deployement works fine on my computer and others, it is only while debugging that I have these issues.
I have been running this down for weeks and spent countless hours looking for a solution and have come to a brick wall. Does anyone have any suggestions?
Thanks ahead of time for your help and time! Please let me know if I can clarify anything.
It turns out that the problem was coming from the fact that somehow one of the folders in the filepath to my user.config file got changed. Somehow a .vshost got thrown in on one of the folder names. I still have no idea how this happened and what caused this to happen, and I am not 100% sure that I have gotten to the real root of the problem, but for now, I am able to debug again. I changed the file name back to what it was supposed to be and the errors have stopped. Now lets just hope the file name doesn't get changed back again.
I have a solution in Visual Studio that is comprised of 5 projects. The projects build to assemblies (.dll). I have the output path of each project set to \my-web-server\wwwroot\bin, which works fine on one project. In the properties for all of my projects, I have the output path set to the same directory, but when I try building all but one of the projects, I get the error:
Unable to copy file "obj\Release\Index.dll" to "\my-web-server\wwwroot\bin\Index.dll". Access to the path '\my-web-server\wwwroot\bin\Index.dll' is denied.
I assume it could be an issue with permissions, because my organization keeps things locked down, but I have no control over granting permissions. Any help in the right direction is much appreciated.
It must've been something silly. I deleted the .dll manually, then rebuilt. Looks like everything's working normally. Thanks.
The solution for me was to delete everything in bin and obj folders in every project. Just ran this powershell script as described here.
I had the same issue. A copy of Visual Studio (devenv.exe) was still running invisible in the background keeping the particular dll locked.
Delete all DLLs from the bin folder and build the solution.
just had the same issue, built a new project/solution, got it all working and then added to TFS.
Unfortunately I did not clean the build before adding and this meant some files that should not have been under source control were and were then read only(not checked out).
Manually deleting the files before rebuilding fixed the issue.
Most likely a program is running using that library.
This happens to me when running something to debug, and I forget to close it (not attached to IDE debugger).
And since this looks like a website, it is potentially due to the website being hosted from the development build folder, and someone is accessing it.
Similar to what Aequitarum said, it's mostly likely a locked file because it's in use. Since you have multiple projects, you mostly likely have references between them. And since you have all the projects outputting to the same folder any of the referenced projects will most likely get copied more than once if you have those files set to be deployed in the child project. (In a C# web application, you can view the properties of the reference and look at the "Copy Local" property.) And if you have the MsBuild project set to use multiple processors for the build, two child projects are both trying to copy the file at approximately the same time and one is erring out.
It's a very unique situation, but it is possible.
Working solution
Just go to Task Manager and search Detail (if its Win10) and search with your application name (for easy search just look at your windows user id wise)
And right click shows properties. just give the permission like Administrator access.
That's all its working fine for me. ( I was struggling for 1 week and its killed more my time)
It looks like WSearch Service locks up the files and does not release them. I disabled the service on WINDOWS 10 and was able to rebuild the solution.
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