December 15, 2015 2:01 pm

Building an app for a 3rd party? How to package their Store app

[This article has been updated to work with both Windows 8 and 10]

This article is specifically for Windows 10 UWP application packaging.  The instructions below may be used to package Windows 8 UAP applications but Step 6 should be ignored.

If you’re a publisher developing your app in-house, stop here. If you’re a 3rd party development vendor who has been given access by your publisher to their Store account credentials, no need to read further. In both of these cases, assigning multi-user account access and packaging your app for the publisher’s Store account is well-documented and straightforward. This article is for developers who need to package an app but are unable to get access to the publisher’s Dev Center account. In this scenario, you’ll have to take some manual steps to ensure that the information in the appxmanifest.xml file matches what the publisher has configured in their Store account. Read on.

Packaging your Windows Store application using Visual Studio’s built in “Create App Packages” wizard is a straightforward and easy way to automatically configure your app’s appxmanifest.xml file with the correct app and publisher ID information for the Store. When you launch the wizard (Project > Store > Create App Packages…) you are asked “Do you want to build packages to upload to the Windows Store?”

1_createPackage

If you select “Yes,” you’re prompted to enter in your Store (aka Dev Center) account credentials.

This is how Visual Studio associates the app with your publisher account so that it can pull down all the correct information from the Store to automatically populate the appxmanifest.xml. However, what if you don’t have access to the publisher’s Store account credentials? It’s common for a publisher to hire a 3rd party vendor to develop their application but retain the Store publishing processes in-house. In this case, the vendor is expected to deliver the packaged app to the publisher who then uploads it to their Store account separately. The “gotcha” in this scenario is that when the publisher attempts to upload the package to their Store account, Microsoft will reject the package with errors because it doesn’t include the correct publisher and app information in the appxmanifest.xml file.

The Create App Packages wizard clearly states that you need to sign into the Store account. Your only other option is to select “No” and you’re told you can only use the resulting package “…on a computer that has a developer license installed…”

2_createPackage

Fortunately, there’s a work-around! Developers can ensure the app is configured with the correct publisher and app information without having to sign into the publisher’s Store account. This does, however, require that the publisher delivers specific information to the developer that they will manually insert into the Visual Studio Manifest Designer before proceeding with the Create App Packages wizard.

Step 1. After the publisher has reserved an app name, have them send you a screenshot of the Dev Center app identity page.

They will log into the Dev Center and navigate to the App Overview for the app. Once there, they’ll choose the App Identity item under App management on the left menu:

3_appId

Step 2. You will open the solution in Visual Studio and view the Manifest Designer for the project (Note: the Manifest Designer opens when you open the package.appxmanifest file, not when you choose the “view code” option). Go to the “Packaging” tab. Click on the “Choose Certificate” button in the “Publisher” field of the form. The dialog below opens.

4_testCert

Step 3. Choose to “Create test certificate…” in the dialog.

Step 4. Enter the Package/Identity/Publisher string (without the “CN=”) you received from the publisher in Step 1 into the “Publisher Common Name:” field. No need to enter a password since this is only a temporary cert used just to get the correct publisher ID to populate the manifest. (Note: When the app has been uploaded to the Dev Center, the Store will automatically strip out this signing signature and will replace it with the Store signature anyways.)

5_publisherCommonName

On hitting “OK” you may get a message asking if you want to replace the existing [YourProjectName]_TemporaryKey.pfx file on the machine. Choose yes.

You should now see the proper “Publisher:” value.

6_appx.Manifest 

Step 5. Populate the rest of the fields:

  • “Package name:” = “Package/Identity/Name” value in the screenshot from Step 1.
  • “Package display name:” = “Name” value from Step 1.
  • “Version:” – whatever you want it to be. Just make sure that it is higher than any packages you’ve already uploaded to the Store for your target Device Family and architecture. Otherwise, users who already have your app installed won’t get the update. More details on app versioning are available here.
  • “Publisher:” – per Step 4 this should be the “Package/Identity/Publisher” value and is automatically populated from the Subject attribute of the signing cert you created in Step 4.
  • “Publisher display name:” = “Package/Properties/PublisherDisplayName” value from Step 1.
  • “Package family name:” – gets automatically populated as a combination of the “Package name:” and a hash of the “Publisher:” value.

After making these changes, save the “Package.appxmanifest” file.

Step 6. In order to force the Create App Packages wizard to build the required “.appxupload” file for the Store, you need to make a simple modification to the “*proj.user” file in your project.  Navigate to your project folder as shown below and open the file with Notepad.  (Note that the “*proj.user” file is only created after you’ve packaged your project for the first time, so make sure you’ve built a debug package with the wizard before trying this step.) Add the following tag as a child within the <PropertyGroup> element and save the file:

<UapAppxPackageBuildMode>CI</UapAppxPackageBuildMode>

update_FileExplorer
Step 7. After saving the file, go to Project > Store > Create App Package. Make sure you select “No” since you’ve manually set the publisher/app manifest values already.

7_createPackage

Step 8. Proceed to build the release packages for the architectures you want to release to. To check that the appxmanifest.xml was created with the appropriate values, unzip the .appx package and open the appxmanifest.xml file.

Following these simple steps, you’ve now created an .appxupload package that the publisher can upload successfully to their Store account. When the Store does its automatic check of the manifest values no errors should be thrown and the package should show up on the Packages page for the app. We hope this article has been helpful. Additional information on packaging your apps for the Windows Store can be found on the Windows Dev Center.

Post written by Tim Harader, Sr. Program Manager at Microsoft

Updated December 29, 2015 12:17 pm

Join the conversation

  1. I’m very happy to see that 3rd party were not forgotten! Some of us also have an internal process where each builds are going on a build server and the “Create your package” step is done with an msbuild task whom is not well documented. When all is automated, we cannot use this simple window. This could be an interesting to have more information on this as well!

  2. Is there any option to create .appxupload for Windows 10 without asking for account credentials?

    • Please note that we’ve updated the above steps to include a modification to the *proj.user file that will allow creation of the required appxupload package for Windows 10 UWP apps.

  3. After the *.appxupload file gets generated, it is not longer possible to debug the application from Visual Studio: the application crashes while displaying splash screen (app runs fine with all changes to property files, critical step is appxupload file generation.). Also after uploading appx file (which is inside the appxupload) to the device, the uploaded app crashes.

    0. Is it standard behavior? I have run a few tests and it always happens. It can only be fixed by reverting VS project files and removing binaries.
    1. What is the reason for such behavior?
    2. How can we be sure that when uploading the crashing app to the destination store account, the app gets “fixed”? We prepared first release of application for our client and were not aware of the problem. The application is uploaded and runs well. However, we are afraid of uploading an update as we do not understand the crash-then-fix process going on behind the scene.
    3. Is VS getting a visual one-click wizard for this process?

    Also, it would be nice to add that at least package store association file needs to be removed from solution before generating appxupload, otherwise VS generates errors 🙂

    • Hi Piotr Gawron, i am also having the same error after following the above steps? did you figureout how to test run the app after .appxupload file is generated?

      When i unzip and try to run on the phone it crashes on the first page. Also, i dont see any App-Package file to run this on windows 10 desktop to give a test run… ? Do you think, i can just assume and publish this to store and test run?

  4. In case at anyone needs to know how to get the above working for VS2017 and for more realistic publisher names (with all the ‘CN=’, ‘O=’ etc bits ) – I worked around issues with these steps :

    1) In example on this page (Step 4) – the publisher name is just a simple ‘CN=xxxx’ string – without all the other bits. Hence when you are up to Step 4 the VS2017 create certificate wizard won’t let you put in the full name (only the CN= part).
    To generate a certificate with all the bits for the publisher name you can use the MakeCert + Pvk2Pfx tools instead.

    for example below the password ‘password’ has been used + I’ve set expiry date to 2049 instead of regular 12 months expiry period (as someone might need to test what has been built after that):

    MakeCert /n “CN=Contoso Electronics, O=Contoso Electronics, L=Redmond, S=Washington, C=US” /r /h 0 /eku “1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.13” /e 01/01/2049 /sv Contoso_AppTemp.pvk Contoso_AppTemp.cer
    Pvk2Pfx /pvk Contoso_AppTemp.pvk /pi “password” /spc Contoso_AppTemp.cer /pfx Contoso_AppTemp.pfx /po “password”

    2) In order to get the .appxupload generation working – I had to do the following for VS2017:

    a) Enable the option (in Project’s Properties -> Build) “Compile with .NET Native tool chain”.

    b) Additionally, in Step 6 – I set UapAppxPackageBuildMode to be ‘StoreOnly’ (instead of ‘CI’) – so this way it created both the .appxupload file and also the test package directory for sideloading.
    Note that when doing this – ‘unload’ your VS2017 Project first and then make changes the *proj.user file. When you reload it the new settings will be used (if doing it while loaded in VS2017 – the new setting will keep getting removed).

    Hope that helps save someone a little bit of time!