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.
Related
I am developing a new application for windows (I am now running it on windows 11), I need, for the features I wanna implement, to create a new entry in windows explorer context menu.
As I checked out I do need to make an installation package and indeed I am using the MSIX-packaged app to wrap my application.
Following this path I found a way to extend the context menu directly on the Microsoft documentation: https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/integrate-packaged-app-with-file-explorer
However nor my code nor the examples brought by Microsoft itself seem to work properly.
I assume it is due to the fact I am developing and running the application on Windows 11 and this method is or incomplete or not working on that Windows version.
Here is the script on the manifest which should add a new entry in the context menu as the app is running.
It is light modification of the same in the Microsoft documentation: I added the <uap10:FileType>*</uap10:FileType>
part for making any extensions to be available for the new context menu entry.
<Extensions>
<uap3:Extension Category="windows.fileTypeAssociation">
<uap3:FileTypeAssociation Name="anyfile" Parameters=""%1"">
<uap:SupportedFileTypes>
<uap:FileType>.foo</uap:FileType>
<uap10:FileType>*</uap10:FileType>
</uap:SupportedFileTypes>
<uap2:SupportedVerbs>
<uap3:Verb Id="Resize" Parameters=""%1"">Resize file</uap3:Verb>
</uap2:SupportedVerbs>
</uap3:FileTypeAssociation>
</uap3:Extension>
<com:Extension Category="windows.comServer">
<com:ComServer>
<com:SurrogateServer DisplayName="ContextMenuSample">
<com:Class Id="CC19E147-7757-483C-B27F-3D81BCEB38FE" Path="ExplorerCommandVerb.dll" ThreadingModel="STA"/>
</com:SurrogateServer>
</com:ComServer>
</com:Extension>
<desktop4:Extension Category="windows.fileExplorerContextMenus">
<desktop4:FileExplorerContextMenus>
<desktop5:ItemType Type="Directory">
<desktop5:Verb Id="Command1" Clsid="CC19E147-7757-483C-B27F-3D81BCEB38FE" />
</desktop5:ItemType>
</desktop4:FileExplorerContextMenus>
</desktop4:Extension>
<uap:Extension Category="windows.protocol">
<uap:Protocol Name="protocolname"/>
</uap:Extension>
</Extensions>
It works properly also on Windows 11 (v 10.0.22621.0)!
The question itself was not really appropriated here, but I hope this related answer can still save some time to someone else.
To make it work I simply had to go into the properties of the package and of the referenced application and, from there, resolve any found conflicts about minimum and the target version, and then downloading the proper SDK, having chosen as main target the v. 10.0.22621.0.
Thanks to you all as always
UWP is killing me.....
I had to reinstall VisualStudio2017 after a computer crash. And now, my app that was working perfectly well before the crash refuses to work.
I've been using the broadFileSystemAccess capability in the Package Manifest, as per the instructions in the MS documentation:
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
IgnorableNamespaces="rescap uap mp desktop4 iot2">
and
<Capabilities>
<rescap:Capability Name="broadFileSystemAccess" />
</Capabilities>
This worked no problem, but now I get an underlined rescap:Capability and the compile warning "The element 'Capabilities' in namespace 'http://schemas.microsoft.com/appx/manifest/foundation/windows10' has invalid child element 'Capability' in namespace .......
Since it's a warning, it compiles without a hickup. However, the application cannot access files (access denied) justa s if this manifest code wasn't there.
I'm holding back saying bad words.... anybody has any idea of what is causing this? It's a fresh VS2017 install.
Thanks!
Ok so heres some of my findings.
1. an app must not declare both broadFileSystemAccess and any of the other three file-system capabilities. (Pictures, documents, downloads)
source: https://social.msdn.microsoft.com/Forums/windowsapps/en-US/415d02da-eeb6-45b3-b6e2-946b124d14b0/broadfilesystemaccess-issue?forum=wpdevelop
2. This only works with the storageFile api NOT File.Exists etc api
source: https://learn.microsoft.com/en-gb/windows/uwp/packaging/app-capability-declarations
3. Make sure the fileAccess is enabled as with the other two answers:
source: https://stackoverflow.com/a/57703368/2987066
4. I also found that every time I started debugging (and the code had changed) I needed to turn that setting on and off again to get it to work
source: frustratingly debugging the application through trial and error
Thanks microsoft for your excellent development environment, it really shows how much developers love developing your apps as your store is really flourishing in comparison to your competitors... oh wait..
Thank you for reporting this issue. It's a known issue in 1809. The relevant team is working on it.
Clint Rutkas has replied on this thread: No user-consent prompt on first run of broadFileSystemAccess-capable UWP app.
He suggested that we could use try/catch to catch this scenario:
try
{
StorageFile storageFile = await StorageFile.GetFileFromPathAsync(#"E:\Foo");
}
catch (Exception)
{
// prompt user for what action they should do then launch below
// suggestion could be a message prompt
await Launcher.LaunchUriAsync(new Uri("ms-settings:appsfeatures-app"));
}
You also need to allow your app access to the file system in Settings. This a safety measure so the user of the machine acknowledges your app can have access outside the controlled access to files provided by the UWP app container it runs in.
Accoding to Andy Wigley on this video https://www.microsoftvirtualacademy.com/en-US/training-courses/a-developer-s-guide-to-windows-10-12618 (look in additional resources -> Localization), UPW apps download only the culture resources they need.
I'm writing an app that uses resource files not only to translate UI but also generate files for the user. User may want to generate files in different culture than the one the OS uses. How I can assure that e.g. if my system is in en-US I will be able to get resources in french?
I may use own XML files that all will be included in the app. But some of the resource for sure will be needed also in UI, so I don't want to duplicate the resources and have to translate them twice.
Rob's answer would work great for a new app, but it didn't work for me, as I had already shipped a previous version of the app as a bundled package. If you then try to switch to a non-bundled package, the store submission portal gives the error:
A previous submission for this app was released with a Windows 10 appxbundle. Subsequent submissions must continue to contain a Windows 10 appxbundle.
After reverse-engineering far too much of the build system, I found enough clues to discover this well-hidden documentation: https://msdn.microsoft.com/en-us/library/dn482043.aspx
Following the steps there, you'll still create a bundled package, but the toolchain won't use Language as a qualifier on which to separate out different bundles. In other words, the neutral package will have all the languages in it, while still bundling satellite packages for Scale (or whatever you like).
In case the MSDN page vanishes, the punchline is that you can override <AppxBundleAutoResourcePackageQualifiers> in your msbuild file to remove the Langauge qualifier:
<AppxBundleAutoResourcePackageQualifiers>Scale</AppxBundleAutoResourcePackageQualifiers>
If you do not want to separate out resources into separately downloadable bundles then you don't need to. When you build the app package you can choose to never create bundles so all resources are included in the main package.
See step six in Create an app package at https://msdn.microsoft.com/en-us/library/hh454036.aspx , but choose "never" instead of "always".
I just discovered that Win8 has a section on the Control Panel called User Accounts and Family Safely with Credential Manager. I'd like to access the credentials stored in there (not to retrieve the passwords but to use them as tokens for a login). So, basically, I'd like to get a piggy-back ride on already installed software.
The closest to a solution has been suggested in this discussion and it's not that close.
Where do I find the assembly for Windows.Security.Credentials.PasswordVault? I've been googling for two hours but I only get information on app development while I'll be targeting desktop.
Is there a way to resolve access to the pre-stored credentials for both Win7 and Win8? I fear a little bit that the vault facility has been drastically remodeled in Win8, making it impossible to target both platforms at once.
How to: Add or Remove References By Using the Reference Manager says:
In the desktop projects the Core tab doesn’t appear by default. You
can add the Windows Runtime by opening the shortcut menu for the
project node, choosing Unload Project, adding the following snippet,
and re-opening the project (on the project node choose Reload
Project). When you invoke the Reference Manager dialog box, the Core
tab appears.
<PropertyGroup>
<TargetPlatformVersion>8.0</TargetPlatformVersion>
</PropertyGroup>
Make sure to check the Windows box on this tab. You should then be
able to use WinRT elements.
I came across the same issue and found out that there is no simple answer anywhere.
This is what I found:
You need to unload the project and add the TargetPlatformVersion as mentioned above.
Add the reference: C:\Program Files (x86)\Windows Kits\8.1\References\CommonConfiguration\Neutral\Annotated\Windows.winmd
Also add the reference: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5\System.Runtime.WindowsRuntime.dll
You can use wrapped Credential Management package. It's an open-source project. I checked it in Windows 7 and it works right.
In order to save your data use following code:
Credential saved = new Credential("username", "password", "MyApp", CredentialType.Generic);
saved.PersistanceType = PersistanceType.LocalComputer;
saved.Save();
And to load your data use:
Credential credential = new Credential { Target = "MyApp", Type = CredentialType.Generic };
credential.Load();
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.