Visual C++ 2010 Fatal Error C1083; Permission Denied

Question

For a class at the university, the professor has provided us with some skeleton code that we are to modify. When I attempt to compile the code in Visual C++ 2010 Express (x86), I receive the following error:

C:\Users\[username]\AppData\Local\Temp\.NETFramework,Version=v4.0.AssemblyAttributes.cpp : fatal error C1083: Cannot open compiler generated file: 'Release\.NETFramework,Version=v4.0.AssemblyAttributes.obj': Permission denied

The account I am logged into has full read-write-modify permissions for the file in question, and I am using Windows 7 (x64). To make matters more confusing, the project compiles in Debug mode, but not in Release mode, which the professor instructed us to use.

Thank you in advance for any help.

Archaeopteryx

Why not asking your admin first? – Frankly

In this case, it's my personal computer, so I am the administrator. – Archaeopteryx

Answer 1

So it turns out that the solution to this was simply to delete the .suo file in the project folder and rebuild the project. Why that worked, I don't know, but it seemed to do so.

Archaeopteryx

For my case I found that .NETFramework,Version=v4.0.AssemblyAttributes.obj file was present in the folder containing binaries for the project. It was hidden. Unhiding it solved the issue. – Kendo

Answer 2

This may not be a permission issue at all but may be a file lock issue. I believe this can happen, if you are:

1. Building the entire solution
2. Building in parallel
3. Not properly defining project dependencies

What happens is one project is writing to the object while another project is attempting to read that object and cannot because the write lock prevents it.

Please correct me if I am wrong.

Disappearance

Answer 3

I never had this specific error but as a general rule, I found that Visual Studio has a lot of issues with security. I can't register COM assemblies on my version for example... For that reason, I always run Visual Studio as Administrator (having an admin account is not enough, you want the shortcut to start as admin). This solves my COM issue and others I've encountered over the years. A long shot, but I hope that helps.

Celestinecelestite

I had seen this on various other forums as a possible solution, so this was one of the first things I tried. Unfortunately, my problem doesn't seem to be linked to this (I can manually find the file and open it after the fact). – Archaeopteryx

Another thing that strikes me as odd here is the filename itself.. First off, I never seen my Visual Studio use the temp folder like that, it should be using the project folder for this. Also, the filename itself doesn't look like a filename but more like a line out of a project file. I would carefully review every single setting you have access to in release mode (the output folder for one) for anything that contains part of the string you see there.You could just delete the release config and redo it from debug too. – Celestinecelestite

So I went through all of the project properties and tested any that didn't match between the Release and Debug configurations with no. Is there another place you would suggest looking (I'm not very experienced with VC++)? – Archaeopteryx

Answer 4

Visual Studio is a bit borked when it comes to generated file access rights on Windows 7 & Vista.

• First, try running Visual Studio Express as an administrator, by right-clicking on its shortcut and selecting the yellow-blue shield option.

• If that doesn't help, disable User Access Control altogether (you should be able to do that with an administrator account).

Blowzed

Running as an administrator was one of the first things I tried, with no success. I tried disabling UAC, and that didn't seem to have an effect either. – Archaeopteryx

Answer 5

I have a solution with multiple projects which I inherited from previous developers. I also have this problem and I finally found out where it comes from, so maybe this is also what happens in the posters case as well.

In my project setup, there are lots of source files which are referenced in the project. When Visual Studio determines the build order, it builds projects, which are independent of each other, in parallel. So it can happen that a file which is compiled in two separate projects is built at the same time, which can cause the lock to happen.

In my opinion, referencing files in a project is evil. :) The proper way would be, to put shared files in a library and then set the dependencies accordingly. Theoretically one can resolve this issue as well, by setting the build dependencies for projects sharing files, but that is IMO arbitrary, because the projects may not have a meaningfull dependency (as it is in my case) they just happen to reuse the same code.

In my case I can sometimes build the whole solution without a problem and sometimes I have to restart it several times.

Another reason this can happen is, when the settings are such that some (intermediate) files are generated into the same folder, so the settings should be reviewed as well.

Priester

Answer 6

If your project compiles fine in one mode and not the other (e.g. Win32 vs x64, Debug vs Release), you should carefully compare build settings, especially Include Directories.

VS will misleadingly throw an "access denied" error instead of "file not found" if your build path contains for example a reference to D: drive which happens to be a DVD-RW drive with no disk inside.

Open Project's Properties > VC++ Directories > Include Directories, select "Configuration: All Configurations" and/or "Platform: All Platforms", if you then see <different options> then check carefully what the differences are. Or simply copy the Include Directories from a working configuration to the broken one.

Then repeat with Project's Properties > C/C++ > Additional Include Directories.

Agripinaagrippa

Answer 7

I had faced the same issue "Fatal Error: Permission Denied" with Visual Studio C++ 2017 under Windows 10.

The sollution was as mention above: To run Visual Studio as Administrator.

Benoite

Answer 8

The permission error occurred for me when using cl.exe with the /Fo flag. Removing the file output option resolved it.

Pasia