Yes, apps in the MAS and Windows Store must NOT have external registration codes.
I have a constant in my app that tells it whether it is compiled for a store or not. If it is on a store, it removes the non-Store registration menu items.
Thanks to eugeneâs indispensable document, I have now fought my way through the DesktopAppConverter process and gotten three appx results that each run on the (VMware) environment they were created in.
I have not dragged copies of any dll 's as suggested in an earlier post and I am using Install Creator Pro from Clickteam to build the silent installer. That all seems to be okay.
Where I get stuck is that I do not seem to be connecting to AppData Roaming. Eugeneâs document mentions that it may not be where I am expecting it to be, but I am not sure where to go look for it.
Has anyone else seen/solved this issue?
[quote=335563:@James Bailey]Where I get stuck is that I do not seem to be connecting to AppData Roaming. Eugeneâs document mentions that it may not be where I am expecting it to be, but I am not sure where to go look for it.
Has anyone else seen/solved this issue?[/quote]
SpecialFolder.ApplicationData is for sure available. My apps would not run otherwise. But do not try to access it with a path yourself in Roaming. In effect, the AppX shows the app a Windows file structure that is in fact within.
Besides, AppX are sandboxed once placed in the Windows Store.
This is gonna take some more exploring on my part. I use SpecialFolder.ApplicationData to set up and access my files. My understanding is that it, on its own initiative, goes to Roaming. That Is certainly what happens in my Windows Xojo builds. But the Appx version fails.
There is a recent (April) Microsoft document that lists all the places that âAll appsâ can access and a separate list for places that Store apps can access. ApplicationData is in the former list, but the latter is pretty much limited to the Downloads folder.
docs.microsoft.com/en-us/Windows/uwp/files/file-access-permissions
My apps are quite large so it takes a while to make new ones. I will try moving my stuff to Downloads and see if that works.
James, you are making it more complex than it should be. Just use a subfolder in SpecialFolder.ApplicationData, and donât try to second guess where it actually is. Let the AppX do its magic and you will be fine.
When you say the AppX version fails, are you trying to access Roaming directly ?
Incidentally, the same situation applies with sandboxed apps in the Mac App Store. SpecialFolder.ApplicationData is not where it is in non sandboxed apps.
i have been trying the DesktopAppConverter on all three of my apps: one self-contained, one with user files, and one with both user files and binaries of open source helper apps. All are quite large. i seem to get consistent results based on the following code snippet:
If App.SwitchFoldersToDownLoads Then
AppSupportFolderFolderItem = SpecialFolder.UserHome.Child(âDownloadsâ)
Else
AppSupportFolderFolderItem = SpecialFolder.ApplicationData
End if
If I switch my folders and files to the Downloads folder, they set up correctly there. If I leave them in AppData, they do not get set up and the app fails. Neither seems to support running helper apps. I do not know what any of this means. has anyone had success in the last month or so creating appx apps that access AppData?
James, I donât understand what may be happening here. In all my Windows Store apps, I simply point to a subfolder within SpecialFolder.ApplicationData. In fact, it is exactly the same code for the non AppX and the Appx.
Dim f as folderItem = SpecialFolder.ApplicationData.child("com.matchsoftware.checkwriter")
if not f.exists then f.createAsFolder
Then I copy anything I need like pictures, save settings and stuff.
Next boot, I load settings and pictures.
Actually, I am surprised you can access Downloads, since it is normally off limit for Windows Store apps.
In a first test the installed .appx Application could access AppData and any other folders.
This is probably because the Converter created an AppX package which displayed âFull Trustâ during installation. Or in other words: âno restrictionsâ.
But maybe Microsoft doesnât allow this once the App goes to their Store? They probably want us to be more restriciveâŠ
I canât say, as I havenât come to that yet 
Any insights and experiences from between having an .appx and âgoing live in Storeâ would be great to read.
No, you are right. They are full trust in the store as well, so they can access any folder. My bad. I was confusing with VS native apps.
BTW this is the reason why you have to go through your own Microsoft rep for him to vet the app before giving the go ahead for full trust.
Thanks a lot for this guide, @Eugene Dakin . This certainly has been a head start.
Meanwhile, Microsoft has quite a good documentation: Desktop conversion for UWP apps
Especially this guide: Package an app using the Desktop App Converter (Desktop Bridge)
Itâs very easy to follow and works just fine with Xojo built Apps. Well done, Microsoft!
I went the route âPackage an app that doesnât have an installerâ. So itâs (no longer?) required to first build an (InnoSetup) installer.
Just put the Xojo App in a âtemplate folderâ, and let the DesktopAppConverter do itâs magic.
Their Parameter Reference is worth looking atâŠ
If you have your own Windows Code-Signing Certificate:
- It seems not necessary to â- Signâ using the DesktopAppConverter.exe
- make sure the âPublisherâ matches exactly to your own CodeSign-certificate. You most likely donât have a certificate with just -Publisher âCN=MyPublisherâ, but more information in that String (location, country, âŠ) For example: âCN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=USâ
- you then can CodeSign the .appx with your own certificate, so itâs not necessary to install that self-created one before you can install your .appx to test the converter app.
What I didnât get working is the Parameter -AppFileTypes (in order to associate file extensions with that app).
What worked is modifying the Manifest manually (after running the DesktopAppConverter) and re-package the .appx.
Eugene has documented this. I just needed to add another Parameter (i guess it was: -l), because of the dpi-dependent assets that seem to be generated today (but not in Eugeneâs guide).
Another way I tried is through an InnoSetup-Installer (where the registry items are being created to associate the filetypes). That has built a good Manifest-template, which I then added to my preferred way (*) âPackage an app that doesnât have an installerâ.
As of today, I donât have the proper file-icon associated yet (it always uses the icon of the app, not a custom filetype-icon). But that seems doable by editing the Manifest appropriately (and adding the icons to the Assets). Iâll try that sooner or later and add the required steps, if thatâs of interest to others
(*) why do I like this better? Well, there is just much, much less ânoiseâ in the Package⊠just compare what gets generated with and without an Installer. I prefer it to be as âcleanâ as possible.
Is there a way to determine if an Application has been installed via Windows Store?
I can look for the subfolder âAppxMetadataâ or files such as âAppxSignature.p7xâ or âresources.priâ next to the exe, which indicate that the Application is within an .appx package. But - is the .appx manually installed (using own CodeSigning) or via Store?
Are there other files added when downloaded/installed via Store?
I guess one way would be to read the Contents of the file âappxmanifest.xmlâ and look at the âPublisherâ (that should be different when installed via Windows Store from what I could read out of the Documentation)? Quicker and less overhead would be to just check for other âApp Store specificâ files.
Why do I ask? Because I need to remove certain functionality (such as âupdate the appâ). And I donât want to build 3 Windows Apps (e.g. using a constant âconstIsAppStoreBuildâ, but use the same built App for all âinstall - casesâ (1. via setup.exe; 2. via Windows App Store; 3. via .appx Installation). 1 and 3 would have an âupdateâ (with either a setup.exe or .appx), 2 obviously not.
I guess you can simply test the app is within an AppX and assume it is in the Windows Store. Even sideload, you cannot update it anyway.
Oh, one could download an update as .appx to a temporary folder and âlaunchâ the .appx (which then updates the already-installed package if the version number is higher).
Sure, as long as the App isnât offered as .appx itâs sufficient to just check for âappx stuffâ around the .exe.
I just like to be prepared for the case itâs being decided (not my decisionâŠ) to offer an .appx alongside an installer.
Thank you 
One question (at the moment)
[quote]Professional Windows 10 or the Enterprise version of the Operating System are able to run the appx
programs.[/quote]
Does this mean that if we are successful getting an app in the store, that people with Windows 10 Home will not be able to use the apps?
Or does this relate to a developer running an APPX for testing without going through the store first?
[quote=338213:@Jeff Tullin]One question (at the moment)
Does this mean that if we are successful getting an app in the store, that people with Windows 10 Home will not be able to use the apps?
Or does this relate to a developer running an APPX for testing without going through the store first?[/quote]
The Pro and Enterprise requirement is just for the developer but the Store app can run on Windows 10 Home.
Following eugeneâs instructions, I am able to create appx files for my apps, but the manifests have two lines referencing ârestrictedcapabilities.â Submission to the App Store fails because of them.
These lines in the manifest seem to be there even with a trivial single line Xojo program.
Is this a common issue? If so, is there a next step?
Hi Jurg,
I am in the final stages of an update for the Get App in Windows Store article, and the /l arguement in the MakeApp command for rebuilding the Appx package causes icons that donât exist to be ignored. To create icons for your App for the Windows Store, you will need to design your png icons. Yes, there are many png files, and each one is for various types of applications. These six pngâs are the miniminum that are needed, and it seemed to work at 150x150
AppStoreLogo.png
AppLargeTile.png
AppList.png
AppMedTile.png
AppSmallTile.png
AppWideTile.png
I use the following MakeAppx command, and it worked on my machine with Version 1703 (OS Build 15063.483):
makeappx pack -d "C:\\MyApps\\MyApp\\PackageFiles" -p "C:\\MyApps\\MyApp\\MyApp.appxÂI am hoping to have the article update finished this weekend. Stay tuned
The latest version of the article is available at Build an Appx Installer for Microsoft Store with Xojo
Updates:
-Latest Windows OS Version 1703 Build 15063.483
-Updates to icons that include building the package and about 50 default icons now used by Microsoft
-No external installer is needed, as DesktopAppConverter.exe does all of this
-Updated new directory locations for MakeAppx
[quote=340975:@James Bailey]Following eugeneâs instructions, I am able to create appx files for my apps, but the manifests have two lines referencing ârestrictedcapabilities.â Submission to the App Store fails because of them.
These lines in the manifest seem to be there even with a trivial single line Xojo program.
Is this a common issue? If so, is there a next step?[/quote]
Hi James,
If you are using APIâs then the Capability XML code may need to be included. Here is an article from Microsoft that may help:
How to Specify capabilities in a package manifest