Install and test an app on other devices
After you develop an app, you can install it on one or more devices so that you can test it. The installation is temporary and is only meant to be used for testing purposes. When you’re ready to distribute your app for production use, you’ll have to either publish it to the Store or side-load it to devices. See Publish your app in the Store, and Sideload Apps with DSIM.
This topic helps you accomplish the following tasks:
Before you can install your app, you must first create an app package by using the Create App Packages wizard.
Choose the No option button in the first page of the wizard. For information, see Create an app package.
When you complete the wizard, the app package will be located in the output folder that you specified in the wizard. The folder contains an .appx file, a security certificate, a Windows PowerShell script, and other files.
To install an app on a phone for testing purposes, use the Application Deployment tool. See Deploy Windows Phone apps with the Application Deployment tool.
Copy the entire contents of the package output folder to the target device.
On the target device, open that folder and find the Add-AppDevPackage PowerShell script alongside your .appx file.
On the shortcut menu for Add-AppDevPackage.ps1 file, choose Run with PowerShell and follow the prompts.
To open the shortcut menu on a tablet, touch the screen where you want to right-click, hold until a complete circle appears, and then lift your finger. The shortcut menu appears after you lift your finger.
On the Start screen, choose the tile that shows the name of your app.
The app starts.
When the app package has been installed, the message “Your developer package was successfully installed” appears. If you are not sure how to respond to any of the prompts that appear when you run the script, see Actions that the Add-AppDevPackage script performs
If the PowerShell script won't run and no error message indicates the reason, the user access control (UAC) on the machine might have been changed. The default UAC setting is Notify me only when apps try to make changes to my computer (default), but it can be changed to Never notify me. If you use a standard user account to log on to a machine whose UAC is set to Never notify me, any changes that require administrator permissions are automatically denied. Under these circumstances, the PowerShell script starts but requires adminstrative permissions to continue. The UAC dialog box doesn't appear, and Windows automatically prevents the script from making changes. To resolve this issue, either change the UAC setting or run the script as an administrator.
The Add-AppDevPackage script performs the following actions.
Prompts you to change the execution policy of your device.
You must confirm that you want to change the execution policy by entering Y. If you enter N, you'll skip this operation and proceed with the next operation. If you enter S, you'll pause the current pipeline and be returned to the command prompt. If you enter the word exit, the pipeline will resume. See Execution policy.
Verifies that you have a developer license.
If the script doesn't find one or your current license has expired, you're prompted to get one. To get a developer license, you must have a Microsoft account. For more information, see Get a developer license (Windows Store apps).
Verifies that any required app packages and certificates are present.
If items are missing, a message asks you to install them before this developer package is installed. For example, if the developer certificate is missing from the local machine, you’ll be prompted to install it. See Developer certificate.
Verifies the presence of any required dependency packages.
Installs any dependency packages and then the app package.
Uses the Get-AuthenticodeSignature function to determine whether to nstall the TEST Visual Studio Certification Authority test signing certificate. See Installing the TEST Visual Studio Certification Authority.
This script displays a warning message about the risks of changing the execution policy on your local machine. The execution policy helps protect you from scripts that you don't trust. If you change the execution policy, you might be exposed to the security risks that about_Execution_Policies describes.
If you launched the script directly from PowerShell instead of by using the shortcut menu, no warning will appear about the risks of changing your execution, and the script will fail. To work around this issue, change the execution policy manually and then run the script again. For more information, about how to set the execution policy manually, see Using the Set-ExecutePolicy Cmdlet.
If you’re prompted to install a developer certificate, you’ll also be warned that installing a digital certificate to your machine's Trusted People certificate store carries a serious security risk and you should do it only if you trust the originator of this digital certificate. When you’re done using this app, you should manually remove the associated digital certificate from the machine's Trusted People certificate store. For information about how to remove a certificate, see How to use the Certificates Console. You must confirm whether you want to continue.
The signing certificates must contain the following values:
Enhanced Key Usage: Code Signing (required)
Basic Constraint: Subject Type=End Entity (required)
Lifetime Signing EKU (optional)
Any other EKUs will invalidate the certificate. If the script doesn't find the required values, an error appears.
When you run the Add-AppDevPackage.ps1 PowerShell script, Visual Studio uses the Get-AuthenticodeSignature function to determine whether it should install the TEST Visual Studio Certification Authority test signing certificate. If the test signing certificate is already installed in the node Certificates – Current User > Trusted Root Certification Authorities > Certificates, the function returns a value that indicates that that the signature is valid. However, deployment of the package will still fail because Windows doesn't trust the certificate. For Windows to trust the certificate, the certificate must be located in either the Certificates (Local Computer) > Trusted Root Certification Authorities > Certificates node or the Certificates (Local Computer) > Trusted People > Certificates node. Only certificates in these two locations can validate the certificate trust in the context of the local machine. Otherwise, an error message that resembles the following string appears: “Add-AppxPackage : Deployment failed with HRESULT: 0x800B0109, A certificate chain processed, but terminated in a rootcertificate which is not trusted by the trust provider. (Exception from HRESULT: 0x800B0109)error 0x800B0109: The root certificate of the signature in the app package must be trusted.” If this error appears, move the test signing certificate into either of the two Certificates (Local Computer) nodes just described. For information about how to move a certificate, see How to use the Certificates Console.