CODEWITHSUNDEEP
c++visual-c++-2010
Aliden
Aliden

Reputation: 451

Visual C++ 2010 Fatal Error C1083; Permission Denied

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.

Upvotes: 9

Views: 16936

Answers (8)

zeno
zeno

Reputation: 81

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

Upvotes: 0

Niki Dimitrov
Niki Dimitrov

Reputation: 86

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.

Upvotes: 0

rustyx
rustyx

Reputation: 85341

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.

Upvotes: 0

Devolus
Devolus

Reputation: 22084

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.

Upvotes: 0

GrumpiestCat
GrumpiestCat

Reputation: 51

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.

Upvotes: 5

Aliden
Aliden

Reputation: 451

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.

Upvotes: 7

Tufak
Tufak

Reputation: 36

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).

Upvotes: 0

user3226053
user3226053

Reputation: 11

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.

Upvotes: 0

Related Questions