Advice on debugging Windows Store app while minimising submissions

[Eric58 6]

I’ve submitted an app to Windows Store that uses the TWindowsStore component to query add-ons the user can buy via In-App purchase.  The app was submitted as “available for private audience only” so that I can continue to debug it before making it accessible to the public.

 

In order to ensure that the app’s license is downloaded to my computer’s cache, I installed the app from the Windows store (via the private link given to me), run it once, then closed it. This is following the instruction here https://docs.microsoft.com/en-sg/windows/uwp/monetize/in-app-purchases-and-trials under the heading "Test your in-app purchase or trial implementation".  Of course, that instruction is for Visual Studio and not Rad Studio, but the principle should be the same.

 

To debug it, I then started the installed app again, and used Rad Studio’s Run/AttachToProcess to attach to that app’s process.  Because the app was built with debug information, I was able to step through the debugger quite well to see where things went wrong.

 

Before continuing I would like to clarify this:  I cannot use the local copy of the app on my computer (built for Normal configuration) to do the debugging; I tried doing this, but I can confirm that the error code returned when querying the store is different from that returned the store-installed app; also the local copy is not able to return any of the submitted add-ons when queried, while the store-installed copy can.   I’m not surprised by this because the local copy isn’t somehow associated with information submitted to the Windows Store.  Just to be sure, I also tried to run the local copy built under the Application Store configuration (that had the same manifest submitted to the store), then attached the debugger to its process, but again that local copy also doesn’t return the right error code.

 

Anyway, after fixing errors that the debugging showed up, I could make another submission of the changes to the Store, then continue testing.  But I would like to minimise such submissions as much as possible while I am still working on the app.  So the question is: Has anyone found a way to associate their local copy of the app to the Store, so that debugging can continue after making changes to the local copy?  The link provided above did say it is something you can do with Visual Studio, but I’ve no idea how this can be achieved with Rad Studio.

[Der schöne Günther 316]

28 minutes ago, Eric58 said:

I’m not surprised by this because the local copy isn’t somehow associated with information submitted to the Windows Store.

I would guess this is because it's simply not packaged and doesn't even have a package id. If you ran the generated .appx file and have not changed anything in the manifest, I would expect it to continue to work - Given that you have already installed it from the store at least once. This is also what the documentation states:

 

Quote

If you have not done so already, install the app from the Store that you specified in the previous step, run the app once, and then close this app. This ensures that a valid license for the app is installed to your development device.

and

Quote

After you complete these steps, you can continue to update your app's code and then debug your updated project on your development computer without submitting new app packages to the Store. You only need to download the Store version of your app to your development computer once to obtain the local license that will be used for testing. (...)

 

Edited June 25, 2020 by Der schöne Günther

[Eric58 6]

Thanks for the reply, but how do you "run" the local generated .appx file?

It is an installer not an exe  - when I double-click on it, a dialog box pops up saying that the app "is already installed", and containing the two buttons "Reinstall" and "Launch".

When I click the Launch button, it launches the store-downloaded version, not the exe file embedded in that local .appx file (I verified this by rebuilding it to have a different mainform caption in order to differentiate).  

 

Then I click the Reinstall button (hoping that I could then run the local copy and attach its process to the debugger), but it fails with the message "Ask the developer for a new package.  This one isn't signed with a trusted certificate."

 

 

 

[Der schöne Günther 316]

The error message means that you will need to add the certificate (the one you used to sign your local .appx) to the "trusted root certificate directories" (or whatever the proper English name is). Have you never run/installed a self-signed .appx before?

 

But yes, it seems that the RAD Studio documentation doesn't mention you need to add your own certificate to the trusted root certificates:

 

https://stackoverflow.com/a/53174601

http://docwiki.embarcadero.com/RADStudio/Rio/en/Creating_a_Certificate_File

Edited June 25, 2020 by Der schöne Günther

[Eric58 6]

Thanks again for your reply.  I still could not solve my problem.  To help explain my situation better, I will differentiate between the two distribution types that an appx file can be generated for:

    Adhoc

    Store

 

I am able to generate an Adhoc appx file that is signed using my trusted local certificate, and so installing that is not a problem. However if I generate a Store appx file, it will be left unsigned (the signing would be done by Windows Store upon submission). Also, the Adhoc appx’s manifest is always different from the Store appx’s manifest file (due to different certificate issuer-ID, among others).

 

Ignoring the difference in manifest (which may or may not be the cause of my problem), I can therefore re-install a local copy of an Adhoc appx file (since it is a trusted app) to override the store-installed app, in order to debug using the local copy of my source code.

 

And here is the exact description of my problem when I debug with this local copy - the local copy’s query to the Store’s API returns different results from the store-installed copy’s query:

1. When calling the store API GetAssociatedStoreProductsAsync, the store-installed copy returns 0 in the ExtendedError value (as it should), while the local copy returns some non-zero value (indicating some kind of error).
2. Consequently, the store-installed copy is able to return the list of add-on products, while the local copy cannot.

Note: For those familiar with the TWindowsStore component, the ExtendedError information isn’t exposed, and I had to modify the dependent unit Winapi.WindowsStore to expose that value.

 

For some reason, when the local copy calls the store APIs, the store is unable to recognise it as coming from a valid app. Maybe it is the fact that the app was not signed by Windows Store, and so the expected credential isn’t passed along in the API calls. 

[Der schöne Günther 316]

Thanks for elaborating. I would have expected both versions to behave the same since they should have the same package id (although different manifests).

 

So it seems like the "Associate this app with a store entry" button in Visual Studio really is necessary. I found no exact details on what it actually does, but maybe these two links are helpful:

1. What does the "Associate App with the Store" wizard do?

2. Submitting an app to the Microsoft Store (MR)
    

   Quote

   From the Project menu in your Visual Studio solution, choose "Store > Associate App with the Store". If you do this, you can test purchase and notification scenarios in your app. When you associate your app with the Store, these values are downloaded to the app manifest file for the current project on your local machine:

   • Package Display Name
   • Package Name
   • Publisher ID
   • Publisher Display Name
   • Version

   If you override the default package.appxmanifest file by creating a custom .xml file for the manifest, you can’t associate your app with the Store. If you try to associate a custom manifest file with the Store, you will see an error message.

    

With no further details, it's probably no fun trying to figure out what VS actually does (maybe by monitoring with tools like Process Monitor) and then re-create it for RAD Studio. I just did some fumbling around in VS, and after getting through the "Associate App with the Store", it generated a "Package.appxmanifest" and a "Package.StoreAssociation.xml" file. Maybe those help. I'm still doubtful whether it actually matters which certificate was used to sign it...

 

Another way would probably be skipping the packaging part in RAD Studio and doing it entirely with something like the MSIX Packaging tool.

Edited June 26, 2020 by Der schöne Günther

[Eric58 6]

OK, I found the solution of how to associate an app in Rad Studio to the store.

The links you posted gave me an idea of what is needed, although it was addressing Visual Studio environment.

 

The solution is to ensure that the manifest file generated for adhoc appx file is identical to the manifest file generated for the store appx.

The reason why they are different is due to the different parameter-gathering approach of Rad Studio:

 

1.  When building a Store appx file, Rad Studio prompts for these 4 parameter values that will be eventually substituted into the manifest file.

• Package Name
• Package Display Name
• Publisher
• Publisher Display Name

2.  When building an Adhoc appx, Rad Studio only prompts you to supply the certificate file, whose Subject value will be eventually substituted as the Publisher value in the manifest file.

 

So there are two steps to take if you want the adhoc manifest file to be identical to the store manifest file for the above 4 values:

Step 1:  Create a new certificate file that has the desired Subject value (ie, Publisher value), and use this new certificate file for adhoc building

Step 2:  Edit the manifest.template.xml file to change the remaining 3 parameters' values accordingly.

 

With these steps, my problem is solved.

Maybe Embarcadero should consider incorporating this as an automated facility within Rad Studio, to save others facing the same problem.

 

Edited June 26, 2020 by Eric58