When I ported the EP Calipers app (an electronic calipers app) to Microsoft Windows, I initially planned to write a Universal Windows Platform (UWP) app. The UWP is an initiative by Microsoft to allow developers to have one code base that can run on all Windows platforms, from PCs to phones to Xbox to HoloLens. UWP apps can be distributed from the Windows Store and are more secure than traditional Win32 programs, as they don’t install DLL files all over the place and don’t write to the registry. These apps are sandboxed, similar to iOS and Android apps. The UWP is a laudable goal, but inherently difficult to implement in Windows which was not originally designed with security in mind, as opposed to Unix/BSD based operating systems like Android and iOS. Unfortunately, I found the application programming interface (API) of the UWP difficult, and so I ported EP Calipers to .NET, creating a traditional Windows PC program. At the time I did this, there was no way to distribute a Windows PC program on the Windows Store, so I was forced to distribute the program via a 3rd party. I would have much preferred to distribute via the Windows Store, as I thought this would create more visibility for the app.
With the Anniversary update of Windows 10, I learned about Project Centennial. This project provides a route to convert Windows desktop programs to APPX format — something that is not quite a UWP app, but something that can be distributed on the Windows Store. After reading the MSDN documentation and viewing some instructive videos, I launched into making the conversion.
The transition has not been as easy as I had hoped.
I downloaded the DesktopAppConverter (DAC) from the Windows Store. Despite this origin, this is not really an app. Instead it runs in a PowerShell (which you must run as Administrator). However before you can run the conversion, you also need to download a “Windows Image” (WIM) file that matches your current version of Windows. This is wim file is something akin to a Windows virtual machine, and the download is large, as you might expect (3.3 Gb). I live in an area with poor internet service (3 Mbps speeds), so it takes longer than a coffee break for this kind of download. I used the Microsoft Edge browser, and it took several attempts to download this file. The browser would declare the download finished, even though only a little more than 2 Gbs had been downloaded. Finally it looked like I had the right number of Gbs, but when I ran the DAC I got an obscure error. I suspected my download was corrupt. Yet another download, using Chrome, got me an non-corrupt download. I wish Microsoft would include a checksum with their downloads, to verify the downloads, but they don’t. Anyway this last download worked — to a point.
Ah, I should have read the fine print. The DAC only works on Windows Pro or Enterprise. I was running Windows Home edition. Sigh. $99 and a short download later, I was running Windows Pro. And I was off to the races — well, not exactly!
DAC works by running your program installer in a virtual Windows environment, and capturing whatever changes your installer makes to the file system and registry. It then encapsulates that information into an appx file that can be uploaded to the Windows Store. The documentation suggests that you can use any installer, as long as it installs silently (i.e. without user input). I had created an installation package using the Visual Studios ClickOnce packaging system. Oops, too bad. That’s the one kind of installer package that doesn’t work with DAC.
In other words they wanted something like an InstallShield installer. An MSI file. Well I had an old version of InstallShield from about 10 years ago. Alas, it was so old that it wouldn’t install itself on Windows 10. Well, maybe I’d have to buy a new edition of InstallShield. I went to the website. Hm, the cheapest version , InstallShield Express, was listed for $699. Yikes!
So I ended up using the Wix open-source installer, with the help of the Wax extension to Visual Studios, to create my MSI installer file (all for free). And so finally I could run the DAC after tweaking the -InstallerArguments (the “/S” silent installation argument as suggested in the documentation didn’t work, and wasn’t needed since the Wix installer I made was silent by default). I also had to make sure my code was compiled as an x64 (64-bit) file, because the DAC only supports 64-bit platforms at this time.
The next step was to sign the appx package. I created a certificate as suggested by the documentation, but it didn’t work. I needed a trusted certificate. Not too clearly documented, it is necessary to right-click on your certificate and add it to the Trusted Root Certificate Authorities. After this, I actually had an appx file that I could install by double-clicking it.
I then spent a few days fiddling with icons. Although UWP apps use 60 plus icon images to create various size tiles, it appears that appx files just need 3 images. These are added to the Assets folder generated by the DAC, and the AppxManifest.xml has to be hand-edited to point to these images. Here as throughout the conversion process, the documentation is quite rough and hard to interpret. The 50×50 pixel size image that is used by the application installer appears fuzzy, so I substituted a higher quality image. I still don’t think that all the icons (for example when using the Open With dialog) work quite right. Anyway, after editing these files, you use the MakeAppx.exe program included in the Windows SDK to recreate your appx file, and then sign it again. I created some PowerShell batch files to do this.
I applied to submit apps to the App Store. I applied as a company, which costs $99 (which the website states is a one time fee, though the email receipt I received mentions “Annual Developer Registration”). Because I registered as a company, I had to wait a few days to be approved, after getting a couple of phone calls from a company whose job is to verify that other companies are real companies — a step that Google and Apple don’t bother with. But EP Studios was duly approved as a real company, such that it is, and all appeared ready for my first Windows App Store submission.
And so I submitted my app. Only to get this error message:
Package acceptance validation error: Your developer account doesn’t have permission to submit apps converted with the Desktop App Converter at this time.
Whaaaaa?? Further research disclosed that even after paying your fee and becoming a certified Microsoft developer, you still have to ask Microsoft “pretty please can I upload apps converted with the Desktop App Converter?” I duly filled out the form to request this. Twice. And I have not heard back from Microsoft.
When I compare this app development and submission process to that of, say, Google or Apple, there is no comparison. The Microsoft process is a chamber of horrors, requiring more time, patience and money than those others. Documentation is poor, and, presumably because not many developers are trying to publish to the Windows Store (I wonder why?) there is very little help in the usual places like StackOverflow. I would Google DAC error messages and get nothing but crickets chirping. All this is unfortunate, especially as I plan to leave for Europe in a few days and I had wanted to get this app uploaded before then. My Windows development machine is a heavy, bulky, desktop (remember them?) computer that certainly is not coming with me.
Maybe by the time I return to the US in a few months, Microsoft will be ready to allow me to submit my app.
Have you heard from Microsoft now? I’ve just submitted an application via https://developer.microsoft.com/zh-cn/windows/projects/campaigns/desktop-bridge.
Thx!
I still haven’t heard back from them. It’s frustrating to view all the videos on how excited Microsoft is to get Desktop apps into the Windows Store, and go through the whole tortuous process of conversion, only at the very last step to find out that they have to approve you even to submit the converted app! They really need to look at how Apple and Google do it, and stop wondering why there aren’t any apps in their store.
Besides, how do you deal with “PublisherDisplayName”? I want to publish it as “Pzoom”, but only “CN=Pzoom” is allowed…
I put just “EP Studios” in the PublisherDisplayName field and left “CN=EP Studios” in the Identity/Publisher field and that worked for me.
Windows Store for Windows Desktop Applications is effectively in closed beta (except they don’t advertise it as such). Unless you’re a big name like Arduino or Kodi they won’t care for you (yet). Maybe in a few months…
Nice of them to let you know before hand.
An update: Microsoft has replied to my request to port the app to the Windows Store and they have emailed me offering assistance. Right now I am on a little “sabbatical” in Europe, but will be able to work again on this project in late December. I’ll be able to make another update on this process after that.