I'm trying to access some files and directories using a UWP app that a local user should have access to for my specific scenario. It wasn't working, so I tested the API on just the general user-level directory and sub-directories to the same effect of E_ACCESSDENIED.
I followed the instructions here: https://learn.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations#restricted-capabilities
Add xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" to the Package
Add rescap to ignorable namespaces (I also tried w/out this btw)
Added <rescap:Capability Name="broadFileSystemAccess" /> to the Capabilities section
Here's a link to the gist for the manifest. It was just a new default Universal app created in VS2017: https://gist.github.com/the-nose-knows/01621d68b7b6a92067780dc69cdf9ded
Here's a link to the gist for the CSProj: https://gist.github.com/the-nose-knows/c95db9fc89e71f38969da9af6203d3a8
The mainpage in the sample project is just one new method and a call to it:
public MainPage()
{
this.InitializeComponent();
GetUserFolder();
}
public async void GetUserFolder()
{
var get =
await Windows.Storage.StorageFolder.GetFolderFromPathAsync("C:\\Users\\user name");
}
So for example, this wouldn't work either:
var get =
await Windows.Storage.StorageFolder.GetFolderFromPathAsync("C:\\Users\\user name\\New Folder");
What am I doing incorrect?
Thank you #Stefan Wick MSFT for providing guidance.
For me, the issue wasn't actually in the code. It had to do how the Restricted Capability works with operating system permissions. There might be a way to help automate this step with PowerShell but I'm not aware of it.
Unlike including another Restricted Capability such as App Close Confirmation with <rescap:Capability Name="confirmAppClose" /> by adding it to the package manifest, you have to also make adjustments to the actual operating system settings for it to take effect. I'm sure this is documented somewhere but it's not exactly prominently warning you about it at the moment let alone telling you how to fix it. Specifically it warns,
Because users can grant or deny the permission any time in Settings, you should ensure that your app is resilient to those changes. In the April 2018 update, the default for the permission is On. In the October 2018 update, the default is Off.
To facilitate those changes,
Enable Settings -> Privacy -> File system -> Allow apps to access your file system
Then find your app after you've installed it, and select the checkbox to allow file system access via Settings -> Privacy -> File system -> Choose which apps can access your file system as shown below.
I was working on a WPF application in Visual Studio 2015 and all went well until unexpectedly the build dropped me the CS2012 error inform me that it cannot access/update the executable in the /Debug directory.
I tried the following and it didn't work:
Restart
Close VS and open the application again
Build->Clean
I couldn't find any solution in the web so I tried:
1. to move the whole project directory to another location.
2. creating a new WPF project and assembling it file by file with copy/pastes.
The weird thing was that in both cases the application worked in the new location. I continued the experimentation (in the original directory) and i tried to build a "Hello World" Console application in the same directory. The result was that the trivial console application didn't work and produced the same problem as the WPF application (CS2012 error).
Since I haven't noticed any activity of another program (i.e., antivirus) trying to quarantine (or changing the file/folder permissions of) this folder, I assume that this has been done by VS somehow but I don't know why. Perhaps it is a bug.
Is anyone has a logical explanation about this problem? And a way to fix it?
I found that my other running solution was referencing the same < executable path>.
Just make sure that no other process is using the referenced folder/file/dll
Try to close all processes, move the project to a different folder (on a different disk) b restart the computer and everything will work as it should. It worked for me without any problems. Hope this helps someone
I wanted to quickly test something in a .NET Core Console Application Solution and ran into this issue due to BitDefender blocking the resulting binaries.
I've named the app client which actually was the culprit. Renaming my solution fixed this.
Sometimes antivirus softwares can block copying an exe file from a folder to any path. You can manage by settings or the easiest way is to shut down live protection while you are coding and debugging.
:)
Deactivate your anti-virus for a while and try again.
This works for me.
I have created a Setup file of my WPF application using Visual Studio setup project.
The setup seems installing ok and I get the installed folder and all the files that are intended to be there.
Now when I run the exe I get following error screen.
Please note when i run the application it runs pretty wel without any issues.
Please note I am using EntityFramework,WPFToolkit and log4net with the application.
And I am installing the application in the rot of C drive to avoid any restriction issue writing the log files.
Can anybody please let me know how I can track what is happening ? I tried 'try catch' in App.xaml.cs OnStartUp and MainWindow constractor returning no exceptions.
Following link has the files mentioned in the error screen :
https://www.dropbox.com/sh/2shp428xcawuk8u/mg5cyXvQ_8
My guess is that your application doesn't have write permission in somewhere.
You just need to find out where it is.
The best solution is to add a listener to Application.DispatcherUnhandledException and see what the real error is. It works even better that log4net.
I get this error a lot, when I try to debug my WinRT app on my local machine:
Error : DEP0500 : The folder "C:\Users\akku\VS2012Projects\ProjectName\bin\x86\Debug\AppX" could not be deleted.
Access to the path 'resources.pri' is denied.
The only thing that fixes it is restarting Windows 8. Googled around a bit and wondered that there was no solution to be found.
After some more testing I realized that this only happens when running or debugging the solution. The problem always seems to be that the AppX folder of the previous run could not be deleted. Maybe the debugger or the Visual Studio process that executed the last application run doesn't stop accessing some resources here?
A quick hack I just used is to create a second Release and Debug-Configuration from the configuration manager. When the problem arises I can switch to another configuration, and the problem is solved temporarily. I still would like a real working answer on how to circumvent this problem with a proper solution.
Has anyone experienced this and found a better fix?
The issue is that I'm working on a Mac with Parallels Desktop and a virtualized Windows 8. As Ryan Joy pointed out in the comment under my question, a workaround can be found on the Parallels Forums.
"The .pri files are being locked because of the feature that shares guest applications with the host OS. As a workaround, I disabled the app sharing feature. I suggest you try this."
If you have Live Share extension, disable it and try to debug.
I am facing a problem for running my website.
I have developed the website and when i hit F5 to view the results i am presented with this error
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.
Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
How can i solve this problem.
This error usually happens if you Map your application folder on Network Drive or open Solution file from UNC Path. somthing like this:
Invalid Example: \\my-server\my-project
Try to open your solution from direct path
Valid Example: C:\Project\MyProject
You can also make change to your privilege of App Pool Identity but it's not recommanded:
Web Server (IIS) > App Pool Identity > Advance Settings > Set Identity as Network Service
the one shot solution worked for me was to set the App Pool Identity(Advance Settings) to Network Service
Try to set "Load User Profile" value of your application pool to "True".
It worked for me.
For what its worth, I found that the AjaxControlKit.dll on the deployed server was blocked. To resolve this, I copied over the dll to a new folder then copied and pasted in the bin folder. I guess .net doesn't like a dll being copied over directly to the web folder
you can run the following command to Grant FullTrust to remote share:
C:\Windows\Microsoft.NET\Framework\v2.0.50727>caspol.exe -m -ag 1 -url
"file:////\yourcomputername\yoursharename*" FullTrust -exclusive on
Hope this helps.
I tried all of the solutions posted here and a number of other places and nothing worked for me. I had my project located on a network drive which worked until I tried to use the AjaxControlToolkit 2.0 in my project. Apparently, something about permissions on the network drive would not allow the controls in the toolkit to run. I moved my project back to my local hard drive and it all started working.
I had this problem as well but have not seen this particular solution mentioned anywhere.
After checking permissions for the IIS user, the user for Impersonation, and granting Full Trust to the application, and still getting the error, I installed Procmon.exe on the server running IIS and noticed that IIS was attempting to access some Framework64 files for the offending website. I inspected the application pool advanced settings and discovered that "enable 32-bit applications" was set to false. Changing this setting to true proved to be the correct action. Life is good.
I face the same problem, then I realised that I was running the solution from a remote folder. Copy the necessary file to the local folder will solve the issue. But make sure that your folder have the full permission
While all of the other answers on this page may be the cause of anyone's problem, the most common one is due to OS security changes in Windows Server 2012 and above. Any file downloaded from the internet is flagged as suspicious by Windows and needs to be manually unblocked before using it in IIS. So if you FTP your code, email it, or transfer it through a cloud provider, it will be flagged and blocked.
The best solution is to use the web publishing facilities built in to Visual Studio or transfer through a network share if you're on a domain, each of which avoid this problem. However, if you must copy your code to another server by one of the means I described above, you should zip everything prior to transfer so you are only left with a single file to unblock. If you unzip before you unblock, then each file will be blocked and multi-selection will not give you the option to unblock.
So finally... to unblock: Right click the file and select Properties. Right there on the first page near the bottom you'll see an Unblock button along with the warning that the file was downloaded from the internet!
If the dll is compiled using this option (Do not merge. Create a separate assembly for each page and control), please make sure the dll is up to date. I faced the error due to aspx file is new one, but dll still using old one.
I found a potential solution that worked on my system and did not require changing to Network Service.
Go to Application Pool -> Advanced Settings -> Process Model -> Load User Profile: True
Source of this answer.
The best way to resolve this issue is Run the Visual Studio as "Administator". Right click on the Visual Studio icon and select "Run as Administrator".
Once you open Visual Studio with Full admin rights, you will be able access the page without any issues.
I have had this error and it seems to be a generic error. As there are several answers to this issue, I am going to add mine. Republishing the website on the remote server seems to fix it for me.