I am trying to copy files from nunit test build folder to nunit runtime folder but getting
Access denied error
I have a folder path setup like Testproject/bin/debug/something.config and tried the options below but its not working for me.
Deleted the bin folder and then rebuilt it.
Opened closed VS.
Deleted bin folder created new bin folder manually.
Tried to remove readonly in folder option but it again gets set to
readonly.
I found these worked for others in the thread
Unable to copy file. Access to the path is denied
I am also using SVN as source control.
One thing that you haven't tried is to run Visual Studio as an administrator. Right click on it, and select run as administrator.
Sounds like it was locked and abandoned.
I've used LockHunter to unlock files that Windows so often locks and abandons. Even after rebooting the files can sometimes remain locked by a process that no longer exists.
It will also tell you what applications have locked the file.
Related
I have an application that is being installed from MSIX installer.
It is installing successfully, but when execute it after installation i get an error that there is no such a file in C:/UserName/AppData/Roaming/MyApplication.
What i have tried:
Creating the folder (from C# code) on the very beggining of the application.
Result: It was creating it somewhere, but i couldnt see it on a disk apparently. Even when i tried creating files in that directory, i could do it without exception. So im sure that this folder existed. Somewhere. When i ran application from MSIX it gave me previously mentioned exception.
I created folder from the OS manually to see if the error will persist.
Result: I ran application from MSIX and everything worked fine.
At the last step i tried to access priviliges to the C:/WindowsApp folder (thats where MSIX are installing things), and i tried to run application from there manually by executing .exe (not by MSIX like previous times), to see if the error will last.
Result: It created those folders without problems, and application worked fine.
Any ideas what im doing wrong, or what i could do avoid this error ?
PS. I cannot change location of path C:/UserName/AppData/Roaming/MyApplication, because it is being created by 3rd parties dll's (Devexpress).
Try searching for the files under this path:
C:\Users\User\AppData\Local\Packages(hash)....
That is where all MSIX packaged apps redirect their AppData resources.
However, if the files are found to be existing in the "real" AppData folder, the app will work with that copy, not the one from the virtualized location (this is international behavior from Microsoft, to smoothen the transition of apps from classic installers to MSIX).
That is why the application worked after you created the folder manually.
Also, note that the files from the virtualized location are accessible only to your application and can't be accessed by others from the machine.
I suspect that when run the EXE directly from the install folder (not from the start menu entry point) the OS does not launch app in the container of the MSIX package, so none of the rules of running as a packaged-app apply. Therefore you can ignore this scenario.
Go back to #1 and try searching for the files under the path I mentioned. How are you (Devexpress) accessing the AppData path? I assume they are using something in the lines of (this should be ok):
Environment.GetFolderPath(Environment.SpecialFolder.)
I'm using visual studio community 2013 on Windows 10 home for development of a c# AI application. The application works fine if it runs from the development folder, however, because I want to be able to keep the application running while modifying and compiling existing code, I copied the exe and DLLs (1 exe, 2 DLLs, debug build) to a different folder to be run from there.
When run from the copied folder, the exe (only the exe) is deleted when I close the application. Moreover, I cannot copy the exe back from the development folder because I get "Destination folder access denied". This happens only when I try to copy the exe (other files, including exes with different names, can be copied OK) and I have to reboot to be able to copy the exe back.
I'm not sure even where to start to debug this. Things I tried:
- Check the recycle bin to see if the deleted file is there: no
- Run process monitor to see if the exe name is running anywhere: no
- Exclude the copied folder from antivirus (AVG) scan/check: didn't help
- Make sure I'm running as administrator: yes
Have you checked the folder permissions on the destination directory? This sounds pretty much closer to a folder permission issue.
Since you haven't mentioned the Windows version in question, I am going to be generic on the approach. Try this:
Go to folder properties -> Security -> Advanced -> Owner -> Edit
Add ownership to your user account
Apply changes and retry copying files as see if it still prevails
** Also, in folder permissions, try giving full control to your user account
Please read carefully: I know that dlls can be in use. I also know about NTFS permissions, and read-only flag.
I create a text file with content hello.
I rename it to .dll
I try to use File.Delete(...) method to delete it: I got
System.UnauthorizedAccessException
I try to open it with File.OpenWrite(...) I got the same exception.
I've turned out all virus checking software.
I am admin in my Windows 7 machine.
I am the owner of the .dll extension file
I can it delete without any warning from the UI.
Using VS 2012 C# program (.NET 4.5)
Any ideas?
Thanks
SOLVED: (partly): This was my firewall :-(. Somehow it cached and sandboxed my project output executable, and restricted to delete .dlls (not .txts). Although I turned off it, and I rebuild the .exe many times somehow the named exe sandboxed state remained active. I stress it was a many times rebuild and binary changed .exe. Congratulations to Commodo just 2 erratic behaviour in on issue. 1) Why the sandboxing is still active if antivirus has turned off? 2) Why not reevaluate the named .exe file and asking me about sandboxing if the binary has changed? How this is turned out? I renamed the project output to x.exe :-(
This was more the 45 minutes from my life and worktime...
For delete try
File.SetAttributes(file, FileAttributes.Normal);
File.Delete(file);
I recently switched computers and copied all my projects over to my new local drive. I reformatted the computer I'm on now so it was pretty much a clean machine. Everything seemed to be working fine, but when I opened one of my projects that I had been running from my old machine, it would no longer compile, and I get the following error message:
Could not write to output file 'c:\Users\user\Documents\Projects\RegressionWeb\OnetouchUpload\obj\debug\OneTouchUpload.dll' -- 'Access is denied.'
I'm getting an error like that for each project I have in my solution. I'm also getting this error:
Unexpected error creating debug information file 'c:\Users\user\documents\projects\RegressionWeb\RegressionWeb\obj\Debug\RegressionWeb.PDB' Access is denied
I've searched high and low, and the only similar issues I could find online related specifically to ASP.NET and IIS, neither of which has anything to do with my project (My projects are class libraries of mostly NUnit tests with some support classes).
I am the administrator on my local machine. I have already taken ownership of every file in the project using takeown /f .\RegressionWeb /r /d y and also tried to ensure that nothing had a status of Read-only, but the following file threw an error when I tried changing the read-only property of it's parent folder:
An error occurred applying attributes to the file:
C:...\Regressionweb.sln.DotSettings.user
Access is denied
Basically this project was working perfectly and had no errors from my old computer. After copying over everything, this DotSettings.user file will not be modified, and Visual Studio can't write to any of the dll files. I'm sure the answer must lie in a Visual Studio setting somewhere. Any and all suggestions would be greatly appreciated.
I think Karl has it right. I had a similar situation once, and what I did was delete the file in question, clean the solution, and then rebuild. If the project needs that file it should recreate it; in my case it didn't need it because it never recreated it, but the project ran just fine.
One other thing I would recommend; you may be selecting the read-only attribute of the parent folder off and selecting this setting to recurse through all sub-folders and files, but that doesn't mean that's what's happening. For all your sub-folders and files (especially the ones that are cropping up as errors) inspect each one individually and make sure the read-only attribute is off.
My money is on your files are read-only. Verify they are read-only and change them or add your files to a source control system and let them get handled by that.
I was able to get this working by closing Visual Studio and then opening it again, but being careful to run Visual Studio "As Administrator". To do this, from the Start menu, right click on Visual Studio and choose "Run as Administrator".
it seems that the same error is sometimes displayed when the app pool user doesn't have access to the %TMP%/%TEMP% folder.
You'll need to grant IIS_IUSRS read and modify access over the temp folder of the user the app pool is running as.
This could either be the temp folder in the app pool user's profile, e.g. c:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp, or the system temp folder at c:\windows\temp.
See if it is related to this:Could not write to output file - Access is denied
. That would be a bit of a bugger to track down. In this case the project is self-referencing the dll and preventing access to the file.
This has a very simple solution, you just have to make sure that your directory name(folder name) is not the same as your file name. I created a folder by the name Pointers, my code was in a file pointers.cpp. When I compiled the code it kept showing the same error. I just had to change the directory or folder name to L1_pointers. You can change it to anything you want and it worked.
I've built a winforms app (C#) that will take a list of file paths, and copy those files (from a different VS solution) to a new location (In a folder the user specifies) in the same directory structure they currently exist on local file system.
I use the Path class, Directory class etc and everything works wonderfully...except when it reaches a file path that points to a DLL.
The DLLs I am trying to copy are a part of the other solution, and that solution is not currently open.
I have tried restarting computer to make sure visual studio isn't somehow hooking into that DLL even after the solution is closed.
The DLL in question can be copied by regular manual means (i.e. copy and paste shortcut).
So short of creating a batch file in the program, and running xcopy on that DLL path, I don't know of a way to get this to work.
From what I have found from google searches (which isn't much on this particular situation), File.Copy() should work..
Any help would be wonderful, even if it is a link to a duplicate question I may have over looked.
Thanks!
-The error message is: The process cannot access the file [insert file path] because it is being used by another process (The path is definitely correct also)
-Just downloaded and tried to search for the DLL name with Process Explorer.. I also ran a similar exe from command prompt to no avail. It claims nothing is using it. That's why I am utterly baffled by this. Also, I just checked the permissions and everything looks great (i.e. Full Control, owner effective permissions)
-It does not handle open files. It basically build the correct src and dest paths and does a File.Copy() on those. How would I go about handling open files? I'm sure I could figure out if it was open, but what would I do it it were open?
It is not complaining about the file you're trying to copy, it is complaining about the file that you're trying to overwrite with the copy. Lots of candidates for that, virus scanners always get very excited about new DLLs, for example. Or it is loaded into a process, the typical failure mode for trying to implement your own auto-updater.
You can rename the target file to make your copy succeed.
Are you in vista or win7? If so, Check your 'User Account Control Settings'. Sometimes this can interfere with .NET security options and prevent file operations that would otherwise work.
As well as Process Explorer, I would use Process Monitor also from Microsoft so you can see what is happening at the point of failure and allows you to see if anything else is accessing the dll.
Possible culprits are
the program you are running,
your antivirus package
a virus.
If the path it is complaining about is the destination path, then is is possible that the path is too long?
Also, when using Process Explorer, make sure you have enabled the option to show details for all processes and not just your own.
I just ran into this issue as well. I tried copying a .DLL from an FTP server to a local directory (replacing the existing one) and for the life of me I could not get it to work. Keeps giving me an 'Access Denied code: 5' Error.
I then realized that the .DLL on the FTP server was not marked as hidden while the .DLL I was trying to replace was marked as hidden.
Once I changed the local one to also be visible. I had no more issues.
So my solution is:
Make sure both files are visible.
Hope this helps someone