Visual Studio output file permissions?

Question

I'am using Visual Studio 2010, how to set or automatically change owner of the output file from Visual Studio (such as executable file) to user other than administrator?

all output files currently is owned by Administrator (due to Visual studio is launch by administrative privilege), so sometime I can't delete those files due to access permissions.

sometime visual studio itself can't delete it too (after i ran the executable) until few minutes, its really annoying when I need to rebuild those executable. anyone know what's the actual problem here?

error message is : error LNK1168: cannot open [path to file].exe for writing

Mickel

Just run into this problem. Same thing, the handle is owned by System process with PID 4. Could you please open up the question again, generally it's better to leave em open even if there is no current answer and this clearly isn't something happening with just your system. – Tardiff

Seems that this fixed my problem.. Thank you.. I have lost much time because of stupid locking issues... – Brassiere

Answer 1

no one give the right answer, so I close this question as a bug within operating system, not in Visual Studio, maybe the O/S is compromised since the file handle is owned by 'System' process (PID 4) and I can't release the file handle since it reporting the file handle is invalid using process explorer.

Mickel

Answer 2

Wooho I finally figured this one out.

It's a bug in Windows 7 and likely in Windows Server 2008 (possibly 64bit versions only). It surfaces when you disable Application Experience service.

Re-enabling this service has fixed this problem for me.

You can't imagine how happy I am, this was making programming so frustrating as it's not just messing with VC, but any compiler and to top it off it's quite random.

A bit more info here as to why it's causing a problem.

List of other SO questions which seem to be related:

• Under which circumstances does the System process (PID 4) retain an open file handle?
• Windows 2008 R2 - Kernel (System Process PID=4) is locking files and folders

Tardiff

This solution is so unexpected that I keep turning off application experience thinking "there's no way this is necessary, probably slows down my machine, etc.". Then a while later I start getting frustrated by locking problems, and turn to Google. I then find my way back to this solution, turn Application Experience back on, and am amazed that it works. I think I've done this 3 times now. – Iodate

This didn't work for me. However my solution loads a lot more quickly now. – Underlie

Thanks, this also worked for me. Visual Studio 2010 could not delete a .dll that it had generated in the previous build. Starting the Application Experience service fixed it immediately! – Waffle

Answer 3

As mentioned above, the fix to this problem is to enable Windows Application Experience Service. Here's how to do this:

1. Windows key + R
2. Type "services.msc" in the window that pops up
3. In the list, find "Application Experience."
4. Double-click on this and change from "disabled" to "enabled"

It should work now! Worked for me :)

Source: http://www.techknowl.com/disable-unwanted-services-and-speed-up.html

Marginate

Answer 4

Well, the file as it is created will be owned by the creator, if you are running Visual Studio as an administrator you are just stuck with it that way from an owner perspective.

Personally, unless you are using IIS for Web Applications I find myself running Visual Studio as a regular user more and more frequently, at least with VS 2010.

In regards to the issue where Visual Studio can not delete the file, I have seen this before with build errors, and sometimes if you have multiple projects that are referencing the same assembly. Your best bet there is try and track down the lock, and then you can either kill the lock, or restart Visual Studio.

I typically use Process Explorer (From SysInternals) to simply remove the handle on the file. (NOTE: this is NOT a "great" idea, but it works....)

Tan

AFAIK Visual Studio is always be run as administrator (one of the case if I need to run debugger), in second case, i don't have build error, and what do you mean by referencing the same assembly?, meanwhile I will try Process Explorer. – Mickel

I've tried Process Explorer, I can close the handle, but how do I know, which process that hold the handle?, its still annoying if I want to rebuild project by always release the handle by Process Explorer. – Mickel

If it is every time, you have something going on in your application, or in your visual studio solution. Do you have the application running outside of visual studio at the time? Is it referenced by any other project? – Tan

no other applications (other than VS), and its standalone project (and/or any project) just simple console application like printf("hello world"); is affected, btw the file handle is owned by System Process if I look in Process Explorer – Mickel