• AddResourcePackageAsync takes the PackageFamilyName of the application as well as the resource ID that uniquely identifies the resource package that you are trying to download. The resource ID corresponds to the ResourceId element in the AppxManifest.xml of your resource package. You can also find this information in your application's AppxBundleManifest.xml which describes all the packages that make up your .appxbundle package.
• Your application must be restarted to get a merged view of all resources that are available to your application, so the API offers the 'ForceTargetApplicationShutdown' option that you can pass to restart your application.
• If there is an update available for your application when you are trying to download the resource package, the API will fail as the older version of the app is no longer available. By passing in the 'ApplyUpdateIfAvailable' flag, the API will update the app as well as get the requested resource package as part of the same download!
• The API returns a progress for the download that you can display in your application. Also note that for Windows store applications, the resource package acquisition shows up in the Microsoft Store 'downloads and updates' page and shows up as an update to your application. The end user can choose to pause or cancel the download of the resource package from the Microsoft Store UX.

private async void DownloadGermanResourcePackage(object sender, RoutedEventArgs e)
{            
    // ResourceId that is unique to the resource package
    string resourceId = "split.language-de";
    // Warn user that application will need to restart.
    // To take update if available pass in the ApplyUpdateIfAvailable flag
    var packageCatalog = PackageCatalog.OpenForCurrentPackage();
    PackageCatalogAddResourcePackageResult result = await packageCatalog.AddResourcePackageAsync("29270depappf.CaffeMacchiato_gah1vdar1nn7a", resourceId, 
        AddResourcePackageOptions.ApplyUpdateIfAvailable | AddResourcePackageOptions.ForceTargetApplicationShutdown)
        .AsTask<PackageCatalogAddResourcePackageResult, PackageInstallProgress>(new Progress
        (progress =>;
        {
                // Draw progress
        }));

        if (result.ExtendedError != null)
        {
                //Display error or retry if needed
        }
}

private async void RemoveResourcePackage(object sender, RoutedEventArgs e)
{            
    var packageCatalog = PackageCatalog.OpenForCurrentPackage();
    List resourcePackagesToRemove = new List();
    resourcePackagesToRemove.Add("split.language-de");
    //Warn user that application will be restarted
    var removePackageResult = await packageCatalog.RemoveResourcePackagesAsync(resourcePackagesToRemove);
    if (removePackageResult.ExtendedError != null)
    {
        // display error
    }
}

During deployment, the App Installer file is validated against the app packages referenced in the Uri element. So the Name, Publisher and Version should match the Package/Identity element in the app package manifest.

New workflow with .appinstaller

App Installer version greater than 1.0.12271.0 is required to support the new features.

Direct Web Install

How does direct web install work?

1. Web servers that support byte range requests (HTTP/1.1)
   • App Packages need to be hosted on servers that support HTTP/1.1 protocol

<html>
   <body>
     <h1>MyApp Web Page</h1>
     <a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubApp.appx"> Install app package </a> 
     <a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubAppBundle.appxbundle"> Install app bundle </a> 
     <a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubAppSet.appinstaller"> Install related set </a>
    </body>
</html>

Web install experience on previous versions of Windows 10

Microsoft SmartScreen integration

Registering Your Stream-able App

Overview of the Streaming Install Debugger

Changing States of Content Groups

Simulating Staging for Content Groups

Sorting and Filtering Content Groups

Enabling and Using the Multi-Select Functionality

New in the Fall Creators Update

• Register loose file apps from network shares
• Install related sets

Register Loose File Apps from Network Shares

1. Enable WDP on the target device
2. From a web browser on your PC, go to https://localhost:50443
   • The browser will display the following message: "There’s a problem with this website’s security certificate". This happens because the certificate which is issued to the Device Portal is a test certificate. You can ignore this certificate error and proceed.
3. In the Apps manager tab, click “Add” and select “Register a network share location”
4. In the text box, specify the path to the AppxManifest.xml file that is located in the root of your app package folder on a network share like so –
5. Now, if the target device isn’t aware of this network share, WDP will prompt the you for your credentials –
6. After successfully providing the credentials, the loose file app will be registered for use. You can either launch the app by finding it in the drop down menu or remove if you no longer need the app.

Install Related Sets

1. Follow steps 1 and 2 from the section above to enable device portal
2. In the Apps manager tab, click “Add” and select “Install packaged application”
3. On PC where the package is available, drag and drop or browse to select the main app package and certificate(.cer) if required. Click the check box to also install optional packages. Click next to specify optional packages.
   • If framework packages are required for the installation of the related set, enable the check box to specify framework packages.
   
4. Again, drag and drop or select the optional packages that you would like to install along with the main app package and click next to start the installation.
5. After successful installation, the installed app will be listed in the drop down menu. Select the desired app and click Start to launch or Remove to uninstall.
   • In case of failure, you will be prompted with an actionable error message detailing the reason.

1. Enable network share access via the app capability declaration in the manifest, specifically "developerModeNetwork"

<Capabilities> <rescap:Capability Name="developmentModeNetwork" /> </Capabilities>

2. The target device where the app will be installed, needs to be in developer mode

1. It's an easy way and safe way to store basic or important metadata about your app extension platform without having to put that information into files. You can use it for important concepts like versioning, permissions, and as enforcement. For example, your app could insist that a "version" field is defined and present in the properties, and have different loading behavior based on that value.
2. The information is stored in the app manifest. This means that it is something that can be indexed and made available via a Store Services API in the future. That means you can bubble it up for display to the user, or have more refined app extension searches for specific properties without having to deploy and load the extension first.

          <uap3:AppExtension Name="com.microsoft.edge.extension" Id="FirstExtension" PublicFolder="Extension" DisplayName="MyExtension">
            <uap3:Properties>
              <Capabilities>
                <Capability Name="websiteContent" />
                <Capability Name="websiteInfo" />
                <Capability Name="browserWebRequest" />
                <Capability Name="browserStorage" />
              </Capabilities>
            </uap3:Properties>
          </uap3:AppExtension>
        </uap3:Extension>

            <uap3:Properties>
              <Version>1.0.0.0</Version>
            </uap3:Properties>

        string extensionVersion = "Unknown";
        var properties = await ext.GetExtensionPropertiesAsync() as PropertySet;
        if (properties != null)
        {
            if (properties.ContainsKey("Version"))
            {
                PropertySet versionProperty = properties["Version"] as PropertySet;
                extensionVersion = versionProperty["#text"].ToString();
            }
        }

Note: In the Windows 10 Anniversary Update, there is an issue where GetExtensionPropertiesAsync() can return null instead of an empty PropertySet if there are no Properties element defined in the extension's app manifest. This will throw an exception in the above example.  If you are using an extension platform that is intended to target the Windows 10 Anniversary Update, be sure to check for this and treat the exception as an empty PropertySet. This issue is corrected in the Windows 10 Creators Update.

1. Set up the App Extension Host declaration in the host app
2. Set up the App Extension declaration in the extending app(s)
3. Use the API in the host app to access the extensions

Create App Extension Host Declaration

1) In your Universal App Project, right-click the "Package.appxmanifest" file and select "view code"

This will bring up the XML view of the appxmanifest.

2) Add the uap3 schema reference attribute if it does not already exist to the <Package> element after the uap reference

xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3"

3) Add "uap3" to the IgnorableNamespaces attribute in the Package Element

IgnorableNamespaces="uap uap3 mp"

The above two steps should result in a package element that looks like this:

4) Add the App Extension Host declaration to the app 

This appears under the Application\Extensions elements:

<uap3:Extension Category="windows.appExtensionHost">

<uap3:AppExtensionHost>

<uap3:Name>build2016.appextensibility.demo</uap3:Name>

</uap3:AppExtensionHost>

</uap3:Extension>

There is only one element to define here, which is the Name. This what we call the contract name; it is how we bind app extensions with hosts. Only extensions matching the name provided will be visible and actionable to an App Extension Host. By convention we recommend using a Name that incorporates your app or publisher name to avoid potential collisions with other apps using extensions.

There is no exclusivity rules for extension declarations; you can have multiple hosts and multiple extensions, and both together in the same app.

Once completed, your application node will look something like this:

Create App Extension Declaration

1) Repeat steps 1-3 in the previous section.

Extensions and Extension Hosts both require the same uwp3 namespace.

2) Add the App Extension declaration to the app manifest, under the Application\Extensions element:

<uap3:Extension Category="windows.appExtension">

<uap3:AppExtension Name="build2016.appextensibility.demo" Id="base" PublicFolder="Public" DisplayName="Grayscale" Description="Grayscale Image">

<uap3:Properties>

<Service>com.microsoft.grayscaleservice</Service>

</uap3:Properties>

</uap3:AppExtension>

</uap3:Extension>

For this declaration you must have the Name attribute value exactly match the Name attribute value of the host declaration. This is a required attribute.

The PublicFolder attribute is the name of the folder relative to the package root that you want to share with the host app. By convention we typically use "Public" but you can use whatever name you want so long as it matches a valid folder in your app. This is a required attribute.

DisplayName and Description are queryable from and can use MRT references, which we recommend for localization support. The MRT references are loaded from the app extension package, not the host app.

The Id attribute is used to uniquely identify this particular extension. This is because you can have multiple App Extension declarations, even for the same host. If you want to have two extensions for a particular host name, then you can do so if you ensure that the Id values are different. App Extension hosts may use the Id value as a clue about what type of extension. For example, you could have one Extension designed for desktop and one for mobile, with the Id being the differentiator. You can also use Properties for that. Id is a required attribute.

The Properties element is filled with custom-defined metadata that is readable by the Host apps at runtime. In this example, I added a property that told the Host app the name of the service that the extension uses. You can also use properties as clues about the usage of the extension, what sort of features or capabilities the extension uses from the Host app, versioning, or many other uses. They are deliberately open-ended so Extension Host apps can specify the type of properties they look for or expect to be present for their extensions. Properties are optional and do not need to be specified.

When you are finished, your Application node should look something like this:

Using the App Extension API in the Host App

Using the API

using Windows.ApplicationModel.AppExtensions;

Creating a Catalog

Extensions listed by creating a catalog for each extension name your host supports.

private AppExtensionCatalog _catalog; _catalog = AppExtensionCatalog.Open("build2016.appextensibility.demo");

The name you specify in Open() should match the name you specify in the host declaration. If you have multiple hosts you must create a separate catalog for each.

Finding Existing Extensions

Once you have a catalog you can use it to discover any existing and current extensions on the system that use that host name.

IReadOnlyList<AppExtension> extensions = await _catalog.FindAllAsync();

This list is a snapshot at the time you call it. Extensions can be added or removed after this call, which is why you need Deployment events to avoid polling them.

Getting Extension Deployment Events

To stay on top of changes to the set of extensions, you should subscribe to all of the extension deployment events:

_catalog.PackageInstalled += Catalog_PackageInstalled; _catalog.PackageUpdated += Catalog_PackageUpdated; _catalog.PackageUninstalling += Catalog_PackageUninstalling; _catalog.PackageUpdating += Catalog_PackageUpdating; _catalog.PackageStatusChanged += Catalog_PackageStatusChanged;

Getting Extension Properties

If you have an extension named ext, then you can get any properties defined in the declaration of the extension:

var properties = await ext.GetExtensionPropertiesAsync() as PropertySet;

Important: In the Anniversary Edition, there is a bug where calling this on an extension that has no properties defined can return null instead of an empty PropertySet. This will throw an exception in the usage above. This is corrected in Insider builds to instead return an empty PropertySet. If targeting the Anniversary Edition as the minimum version you should either test for a null return or catch and handle the exception.

Reading the Public Folder

You can read the contents of the PublicFolder specified by the app extension declaration using the catalog:

extensionfile = await folder.GetFileAsync(fileName);

Testing Extension Hosts and Extensions

• Run host and then deploy Extension app
  • Does the host pick up new extensions that come along while its running?
• Deploy Extension app and then deploy & run host.
  • Does the host pick up previously-existing extensions?
• Run host and then remove extension app.
  • Does the host detect the remove correctly?
• Run host and then update the extension app to a newer version.
  • Does the host pick up the changes and unload the extension properly when you get update events?

• Run host, move extension app to removable media, remove that media
  • Does the host detect the change in package status and disable the extension?
• Run host, then corrupt the extension app (make it invalid, signed differently, etc.)
  • Does the host detect the tampered extension and handle it cleanly?
• Run host, deploy Extension app that has invalid content or properties
  • Does the host detect invalid content and handle it cleanly?