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
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 am trying to create an updater which will replace the files in the folder without needing an installer. As part of this process, I need to be able to delete old files and replace them by new files. I tried it and got an UnAuthorizedException. I am runing the updater as administrator. I tried the following
a. Setting the file and folder attribute to Normal
[Access to the path is denied when trying to delete a certain directory
b. Taking ownership of the folder and files contained in it
[Taking ownership of a file or folder
c. Changing the permissions and giving all users full control over the folder and files [Using a custom action in the installer]
[How to give Read/Write permissions to a Folder during installation using .NET
d. Running the updater from a windows service
There is no difference in the results. I keep getting the access denied error. What do I do so that the updater can delete the files?
It's not clear exactly what you mean by "running as administrator", but being logged in as administrator and running a program does not mean that the program is running with elevated privilege, which is what it really needs. But clearly the updater program is not running elevated.
So the issue might be that this updater program of yours needs an elevation manifest so that when you run it, it will ask for elevation with a UAC prompt.
Having said that, simply replacing files that were installed with a Windows installer MSI is not supported. The files must be replaced with a Windows Installer update such as a patch .msp file or an upgraded MSI file. Windows Installer keeps track of every file installed, and it's version and whether it's been updated or not, as well as a filehash. Replacing a file without using Windows Installer can result in unexpected demands for the original MSI file in order that Windows can restore the files to their original installed state. You might find that going to Programs&Features (or right-clicking the MSI file) and choosing repair will also restore them.
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 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.
I'm trying to make an uninstaller.
I basically need to be able to remove a directory in the program files that contains the uninstaller.
I was thinking to have the uninstaller create a copy of itself to the temp folder,
then have the uninstaller running from the program folder open the uninstaller in temp and close itself where it continues the uninstall.
Problem is, how do I delete the uninstaller in the temp folder...
Check out: https://www.catch22.net/tuts/win32/self-deleting-executables
He has multiple solutions - but mostly aimed at C++ code.
I am currently trying to implement the "DELETE_ON_CLOSE" method in C#.
A comment to all the nay-sayers: MSI does not solve this problem in all cases. In my case, my application needs to install to a network folder, where any network user can run the app. It also needs to support upgrades and uninstalls from any network workstation - not necessarily the same workstation that installed the app. This means I cannot register an Uninstaller into the Add/Remove Programs list on the local machine. I must create an Uninstall.exe that is dropped into the install folder. MSI does not support that, so I have to write my own.
Even though I agree with everyone saying you shouldn't do that, what you can do is:
Have your program create an executable (and config file) in the temporary folder of the OS it's working on.
Have your program start it as an independent process, then exit.
That executable then calls back the actual setup stuff.
Once the setup is done, the temporary executable can delete the setup files.
Since the only trace of your program is now in the temp folder, it will eventually get cleared automatically.