1

I am compiling a bigger VB.NET project using VS2012.

Randomly, but very often after having run my project in Debug Mode, I get the error

"The output file <mypathhere> could not be written. Permission denied."

I have also tried using MSBUILD to give me more details about this error, but it didn't help. Also, I have tried disabling the Hosting option because I thought that this might be the cause, but it wasn't.

I used ProcessExplorer to find out which process might have locked my file, but it didn't show anything.

Does anybody have any more ideas?

When I try to set the application's output folder to not-writeprotected using the Windows properties dialog, I get the "Changing attributes denied. Permission denied." error on the output file.

Thank you very much!

tmighty
  • 10,734
  • 21
  • 104
  • 218

2 Answers2

0

There are a couple of reasons why this could happen

  • An instance of your program is currently running hence Visual Studio can't write over the file. Next time this happens check and see if any instances of your program are running in task manager.
  • An anti-virus program has a lock on your file to analyze it and prevents VS from overwriting it. Try excluding your project director from analysis and see if the problem dissapears
JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • Hi Jared, I have seen this question a lot now, for example here: http://stackoverflow.com/questions/18102859/visual-studio-could-not-copy-during-build I do believe that in the end it is the user's fault, but can you tell me how to ask the MS guys to invest more time into this problem? I mean it would be great if the compiler / IDE could give us users more hints about where the problem might be located. – tmighty Mar 30 '14 at 21:13
  • Did you see the solution? How do you feel about such situations? Are you more forgiving because these guys sit in the same building, or do you also bite in the table when something like that happens? I would really like to find out more about what it's like at MS. Luckily some MS guys have blogs, so one can read some things if they want to. – tmighty Apr 02 '14 at 20:11
0

The solution is to activate the Application Experience service in Windows. This is a known MS bug.

tmighty
  • 10,734
  • 21
  • 104
  • 218
  • After some weeks, I got the problem again, even with having Application Experience activated. The solution was to add the following to the pre-build options (I saw that on a different post): if exist "$(TargetPath).locked" del "$(TargetPath).locked" if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked" – tmighty May 13 '14 at 14:53