Some important SDKs (like SQLite for Windows Runtime or Bing Maps SDK) are only available as Visual Studio extensions (also known as “Extension SDKs”). This means that in order to use them, you have to install a .vsix package via Visual Studio. Such an extension is therefore installed per-machine, which means that if you are developing multiple apps on that machine, you have to only install the extension once. On the other hand, if a single app is being developed on multiple machines (in a team environment, this is most often the case), the extension has to be installed on each machine separately.
This capability has probably one of the most misleading names from all capabilities available for WinRT apps. You might think that it would work similar to musicLibrary or pictureLibrary capabilities: just as they allow you unlimited access to user’s Music or Picture library folders, documentsLibrary should allow you to access user’s Documents… right? In a way, it indeed does, but if you want to publish your app in the Store, there are so many limits to its use and things you need to be aware of that I’ve decided to dedicate a special post in my WinRT filesystem series just to this capability.
In a previous part of this series, we’ve discussed which predefined folders are accessible to WinRT apps and how to make use of them. In this part, we will take a look on how you can use GUI pickers to access other files and folders.
Using File and Folder pickers
There are three pickers available, all residing in namespace Windows.Storage.Pickers :
In a first part of this series, we will examine which predefined folders are available to you in WinRT and what are the constraints you have to live with while working with them.
Predefined app-specific folders
Every app has access to several folders that are accessible only to that particular app and no one else. You don’t need any additional capabilities to be able to work with these folders.
Since WinRT apps run in a sandboxed environment, there are limitations on how and when they are allowed to access user’s files and folders. Still, there are several approaches that allow at least some degree of flexibility in this area.
To Store or not to Store?
Exactly how flexible you are allowed to be depends mainly on whether or not you want to publish your app to the Store; even if you care about Store publishing, there is still a way to gain access to some more exotic app capabilities by using a Company account. So basically, there are three possible scenarios you may find yourself in:
- You want to publish your app to the Store and have an Individual account.
- You want to publish your app to the Store and have a Company account.
- You don’t care about the Store (and will probably use sideloading to deploy your app).
In first part of this series, we’ve discussed some basics regarding the client certificate authentication in Windows Store apps. Now, we are going to wrap that discussion up by examining how to work with application certificate storage and how it can be used to specify a particular certificate for HttpClient to use. This post builds upon background from the first part, so if you haven’t already done so, please, read it first.
How to get the certificate to app store
As a first step, let’s see how is it possible to get some certificates to that application storage. There are actually two ways to do that, each with its pros and cons.
Importing the certificate from file
You can simply import the certificate from the file by calling CertificateEnrollmentManager.ImportPfxDataAsync method:
// let user pick the certificate
FileOpenPicker fileOpenPicker = new FileOpenPicker();
StorageFile certificateFile = await fileOpenPicker.PickSingleFileAsync();
// ImportPfxDataAsync accepts the certificate as a Base64 string, so we need to encode it
IBuffer certificateBuffer = await FileIO.ReadBufferAsync(certificateFile);
string encodedCertificate = Windows.Security.Cryptography.CryptographicBuffer.EncodeToBase64String(certificateBuffer);
await CertificateEnrollmentManager.ImportPfxDataAsync(encodedCertificate, "Client02", ExportOption.NotExportable, KeyProtectionLevel.NoConsent, InstallOptions.None, "certificateOne");
Authentication via client certificates is often used in enterprise environments to provide additional layer of security. Since I recently spent considerable amount of time on how to get it working in Windows Store apps, I decided to summarize all bits of knowledge I hoarded to a two part blog series. Big thanks to Prashant Phadke from Microsoft for keeping up with all my questions!
Sending HTTP requests in Windows Store apps
Let’s start by discussing how you should be sending HTTP requests to be able to work with client certificates. It’s not that straightforward since in WinRT, there are three options available: