Prevented from opening visual studio because of inability to write to folder WPF

[gomathip02]

Copied from VSO ID: 1068111 A few days ago I was attempting to build/deploy a web site to a subfolder of C:\inetpub\wwwroot. After using Internet Information Services (IIS) Manager to create the folder, I tried using Visual Studio (2019) to build the web site. My 1st attempt failed, and I was instructed - I believe by a Visual Studio diagnostic - that I would have to run Visual Studio in Administrative mode. I tried again after restarting Visual Studio in Administrative Mode, and the Build was successful. But, from then on I was unable to reopen Visual Studio without Administrative Mode: the diagnostic was displayed in an ordinary popup box with an OK button, and with the text “Cannot write to folder C:\user\sncole\AppData\Local\Temp\WPF. Access is denied”. (It is possible that I caused this error when I tried to reopen Visual Studio before closing it while it was in Administrative Mode.) I used Google Search extensively to try to find some other user with a similar experience; no luck. Finally - a day later - I stumbled on a work-around. I tried to open C:\user\sncole\AppData\Local\Temp\WPF with Windows Explorer; Windows Explorer similarly informed me that access was denied, but it asked me whether I wanted to override the access denial. I said “yes”, and I was allowed to view the contents of C:\user\sncole\AppData\Local\Temp\WPF. Since then I no longer need Administrative mode to open Visual Studio.

The issue here is that a WPF folder is getting created in the temp directly with wrong ACLs.

[lindexi]

Maybe it is Prevented from opening visual studio because of inability to write to folder WPF problem.

@gomathip02 Could you try to write this code to your main method?

        Environment.SetEnvironmentVariable("TEMP", tempFolder);
        Environment.SetEnvironmentVariable("TMP", tempFolder);

The tempFolder is your custom folder full path.

And I do not know why the C:\user\sncole\AppData\Local\Temp\WPF folder can not be wrote. This code can only change the Path.TempPath to your folder

[rladuca]

@lindexi @gomathip02 is a PM on the WPF team, this is just copied here from an internal bug.

[lindexi]

@rladuc Thank you and sorry.

[rladuca]

@lindexi Nothing to be sorry about, I just wanted to be sure you weren't trying to help someone who wasn't going to need it. Definitely appreciate the attempt!

[madewokherd]

It probably shouldn't be using a hard-coded name for its temporary directory.

[NathanS-Microsoft]

MS employee but just another user. Got around this one by rebooting and deleting the temp\WPF folder. MSVS can write to it if it creates it :)

[vatsan-madhavan]

If the first process that creates $env:temp\wpf happens to be an elevated process, then the subsequent unelevated processes that try to write to it (processes that try to write to it = WPF apps with spell-check enabled + also use custom dictionaries) are probably getting denied.

Typically the reverse happens more commonly - i.e., some unelevated process instantiates $env:temp\wpf and later on elevated processes also share the same location, which probably works out just fine.

FileHelper.CreateAndOpenTemporaryFile I think needs use the least required ACL's on the folder it creates so that when elevated processes create the $env:temp\wpf folder for the first time, subsequent unelevated processes are also able to share the same temp folder.

https://github.com/dotnet/wpf/blob/40775430dc86d110ba7b83ca5a898b8f4e9335e7/src/Microsoft.DotNet.Wpf/src/Shared/System/IO/FileHelper.cs#L92-L97

@NathanS-Microsoft's workaround ought to work. 👍 . Also consider something like this:

• Stop all WPF processes (or just the subset of processes that have a handle open to $env:temp\wpf).
  • Sysinternals has a handy tool called handle that could help with this.
• Delete $env:temp\wpf
• Create $env:\temp\wpf as a limited user
• Restart applications/processes of interest.