How to add my AutoHotKeys App in to Microsoft Store ?

[jkeks]

Is there way to add my AutoHotKeys App in to Microsoft Store ?

[BNOLI]

What about asking this at the Microsoft Store ???

[mslonik]

Dear Forum,

I'd like to resurrect this thread, as it never was properly answered. To make it short (protection against TLDR, Too Long Didn't Read):

• I wasn't able to add my AutoHotkey based application to Microsoft Store.
• No way to get feedback from Microsoft personnel.
• Not sure if issue is related to Microsoft or AutoHotkey.

If you're interested, read on.

---

What conditions must be met to establish Microsoft Store?

• General introduction (by Microsoft): Publish Windows apps and games.
• Detailed list of steps (by Microsoft): Publish your app in the Microsoft Store
• Even more details (by Microsoft): Microsoft Store Policies

---

What path did I take?

1. EXE: MyFile.ahk → ahk2.exe → MyFile.exe → NSIS installer → MyFileInstaller.exe → upload to Microsoft store → validation → rejected on time of validation
2. MSI: MyFile.ahk → ahk2.exe → MiFile.exe → NSIS installer → MyFileInstaller.exe → exemsi wrapper → upload to Microsoft store → validation → rejected on time of validation

Disclaimer: I didn't use (yet) neither orca (by Microsoft) nor wix.

---

What specific problem do I face?

My problem is unsuccessful validation:


In particular, I get the following messages:

• Entry in add or remove programs
• Bundleware check

Unfortunately, provided comments do not help me to resolve this issue by myself. Microsoft support is granted on later stage, when application passed automatic validation.

The NSIS installer which I use is located on GitHub: Hotstrings-NSIS_installer.

Any help is appreciated.

---

Why I even wonder if issue is related to AutoHotkey or Microsoft?

As far as I know what is produced by
MyFile.ahk → ahk2.exe → MyFile.exe

is actually wrapping of MyFile.ahk with AutoHotkey.exe (or .bin). Maybe process of validation is able to detect it?

Disclaimer: perhaps anser to this question is would be answered if I prepare very simple HelloWorld.c and try to validate it? I didn't do that, to be honest.

---

General questions:

• Are there anyone who is reading this forum and succeeded with above challenge? How did you manage?
• Or is it only me and mine specific issue?
• Can anyone who has already established Microsoft Store account can try to pass validation of simple HelloWorld.ahk application to confirm if it is even possible?

The problem was already discussed at least partially on this forum in the thread "Autohotkey within the Microsoft Store", but please join this thread: @JnLlnd, @Joe Glines. @Weatherlight would you mind to provide some advice?

Potential benefits of promoting AutoHotkey scripts in Microsoft Store are so numerous, it is worth to dig in.

Kind regards, mslonik ()

[JnLlnd]

Hi @mslonik,

A user of my application suggested to add it to the Microsoft Store as it would allow more users to install it on their company's computer. It seems that more and more IT departments only allow users to install on their PCs applications from the MS Store.

But from the info I got about publishing on MS Store (mostly from you - thank you!- and @Joe Glines), I came to the conclusion that publishing on MS Store is not for a freeware developer like me. And this for various reasons including above all registration cost and heavy paperwork. I already did the paperwork for my code signing certificate and I pay $$$ every two years to renew it. I don't see enough additional benefits to do it again for MS Store.

But I agree it can be a good option for paying software. Good luck with the next steps.

PS: I agree this thread could be moved to General discussion for more visibility.

[Descolada]

@mslonik, you should be able to add AHK scripts to the Store, but not in compiled form. Add the script and the base AHK executable to the package, then add the application to the manifest with Executable set to the AHK base file, and uap10:Parameters set to your script file. That is how I added AHK Store Edition, which runs the Dash as an entrypoint.

Be prepared to give explanations to Microsoft as to why your executable is not written by you and what kind of licencing is needed...

You can get help from Microsoft by writing to [email protected]. I think there is a paid dev support available as well, which might be a better option if you have questions about the submission process or need more general help.

[mslonik]

Actually there seems to be technical obstacle. According to Microsoft Store policy clause 10.2.2 (2023-12-08):

Your product must not attempt to fundamentally change or extend its described functionality or introduce features or functionality that are in violation of Store Policies through any form of dynamic inclusion of code. Your product should not, for example, download a remote script and subsequently execute that script in a manner that is not consistent with the described functionality

It might mean that if you wish to publish in Microsoft Store script bundled with interpreter, then you act against above clause. No matter if you wish to publish AutoHotkey script or Python or whatever else.

@Descolada: thank you for your reply. This could be direction, which I should investigate further, definitely. I've already contacted Microsoft support and received feedback with no substantial help. I'll try to write on Microsoft dev forum as well.

What I actually want to do is to add:

• free version, so it can be a script in source form (.ahk)
• compiled / bundled / executable form as I don't want to share publicly some parts of code

I'm afraid the latter might not be possible .

By the way, what tool have you used to prepare MSIX package?

[Descolada]

@mslonik

Your product must not attempt to fundamentally change or extend its described functionality or introduce features or functionality that are in violation of Store Policies through any form of dynamic inclusion of code. Your product should not, for example, download a remote script and subsequently execute that script in a manner that is not consistent with the described functionality

I choose to interpret this as "you can't fundamentally change what your program does using dynamic inclusion of code", meaning if your app is for example a video player app then you can't make it download and interpret a script to start listening to the microphone or keylogging. I don't take it as a blanket ban on scripting languages, and also if it were enforced as such then dynamic updates to apps wouldn't be possible (yet at they moment they are, for example VSCode from Store auto-updates). Just make sure that if you do dynamic inclusion of code that the added functionality is in concordance with the Store description of the app, and that it doesn't violate Store Policies.

I'm afraid the latter might not be possible .

I'm afraid so too. I mean theoretically you could communicate with a Store rep and talk it through (perhaps share the source code, give compilation instructions etc to prove your program isn't malicious), maybe they'd make an exception, but I wouldn't count on it.
You could perhaps take a look into the traditional desktop app publishing route, maybe they are more lenient with that.
Another option would be code obfuscation.

EDIT: it seems that MakeAppx.exe also has an "encrypt" flag to create an encrypted app package. Something to test out perhaps?

By the way, what tool have you used to prepare MSIX package?

I used MSIX Hero to package into MSIX, and MSIX Packaging Tool to sign the package and modify smaller things if needed (eg virtual registry).

[mslonik]

I already tried to find help from Microsoft official support by http://aka.ms/storesupport → "App Submission & Management". I received feedback which didn't help me at all, and my request was politely "archived". But I received next suggestion to publish my question to Q&A of Microsoft Learn. Why not, I asked myself.

So for those of you, who are interested in this subject, click is-it-possible-to-publish-script-originated-applic. I asked actually quite general question:

Is it possible to publish script originated application in Microsoft Store?

I'll keep you informed in this thread if something valuable will be answered in the Microsoft one.

Kind regards, mslonik ()

[mslonik]

Conclusion:

According to the response from the team you got, it seems that script originated application can't be published to the Store, you might try to distribute your app via sideloading.

By the team it is understood Microsoft Store team.
By the script originated application it is understood bundled AutoHotkey interpreter and a script in form of EXE file.
By the sideloading it is understood distribution of executable outside of Microsoft Store, by your own means, e.g. website / other web store. In such case, the executable must be signed by appropriate SSL certificate.

My conclusion: at least this subject is clear now.

[lexikos]

I think AutoHotkey already having been published on the store, packaged with scripts, demonstrates that it is possible. I believe there are many apps that are built on JavaScript, for instance. I'll also point out that "AutoHotkey Store Edition" includes Ahk2Exe, which is a compiled script.

Your screenshot seems to be indicating that the app name or publisher name that the validation process detected does not match the registration of your package, and therefore is detected as including bundleware. Perhaps this sets the "10.2.2 flag", which then caused you to receive the canned response about that policy. It seems to me that the response given on Learn was only an interpretation of this canned response, by someone who is on the outside, like us, not on the inside, validating apps or enforcing the store policy.

Executing a script included in your package using an interpreter included in your package is not "dynamic inclusion of code". Your package includes all of the code, does it not? Especially if the code is included in the package and never changes, "fundamentally change or extend its described functionality" is clearly not happening. Add to that, if the condition "that are in violation of Store Policies" applies to the whole sentence, it isn't even banning the dynamic inclusion of code, only the use of such to violate other policies.

[Descolada]

I was about to mention that a compiled AHK script, namely Ahk2Exe, is already in the Store in AutoHotkey Store Edition, but @lexikos beat me to it! However it doesn't mean that *any* compiled script can be published, because when I tried to use a compiled script as a shell redirector (eg called when script is right-clicking and "Edit" is pressed) it also got flagged and denied. I asked the author of Ahk2Exe @TAC109 about his compilation procedure and he replied

I was having problems with the downloads of Ahk2Exe being flagged as suspicious, so in March 2022 I submitted a false positive report to Microsoft. Ever since then I have not encountered any further difficulties! Ahk2Exe is just compiled normally with no compression using AutoHotkeyU32.exe as a base file.

This means that you might need to follow the same procedure to get it accepted, but I haven't tried it out.

Also, I think lexikos has a point that maybe AHK isn't the cause at all. It might be that you need to package directly to MSI without the NSI step, or try to use the MSIX format instead, because maybe NSI is being flagged as bundleware. Are you sure that NSI can be used to publish to Store?

[mslonik]

I didn't give up yet. Thank you for supporting my pursuit with your comments.

To sum up what I know till now and separate it from what I only assume.

There are 3 general paths to enter Microsoft Store with a "package":

1. Executable file, EXE.
2. Microsoft installer, MSI.
3. Microsoft new installer, MSIX.

The 3rd path is recommended by Microsoft.

No matter which path you take, you must prepare an installation package with some additional steps. When your package is ready, it must pass Microsoft Store validation, which is automatized. From Microsoft perspective, the whole process is fairly easy. All you need is Visual Studio Professional (by Microsoft), and then you can just choose available options from the menu.

Theoretically, you can accomplish the process with other tools too, as manuals (prepared by Microsoft) are available over web.

Till now, I took path no. 1 with NSIS (Nullsoft Scriptable Install Service) tool and no. 2 with wrapper. Both tools are available for free. I wasn't able to pass validation. There could be numerous reasons for that. The challenge is that feedback from validation is not sufficient from my point of view to conclude what's actually wrong. My hypothesis:

1. Formal data is not linked correctly between expected fields / positions / tags between installer and Microsoft Store database. For example, company name is not recognized / read in / wrote in correctly.
2. Code of installer is not transparent, brings some doubts about inclusion of "foreign" / "other" code.

There is no clear way for me to conclude or exclude any of those, but I'd like to share one finding. I decided to follow the suggestion of Descolada (thank you!) and prepare "bare installation package": no executable inside, only .ahk script file, no uninstaller. So basically speaking bare minimum required. This package also failed validation. Then I asked myself what is inside of installer EXE. When I opened the installer EXE with ZIP application: there is $PLUGINSDIR subfolder, which contains System.dll file. Maybe this file is treated as "dynamic code"?

Leaving aside NSIS installer, I decided to follow another suggestion of Descolada and try out the third, by the way recommended, path: MSIX. Here are my findings so far.

1. Download Microsoft SDK installer. (SDK = Software Development Kit)
2. Run the installer as administrator. If this condition is not met, the makeappx.exe will not be installed. My version is of SDK installer: 10.0.22621.2428.
3. Select Install the Windows Software Development Kit to this computer.
4. Decide about Windows Kits Privacy, agree to license agreements.
5. Select the features you want to install: it is enough to mark Application Verifier for Windows and Windows App Certification Kit.
6. The required file was found in C:\Program Files (x86)\Windows Kits\10\App Certification Kit\makeappx.exe .
7. How to make a package.
8. How to make a manifest XML.

Comments:

1. Lack of manifest file and/or formal details within manifest file could be the reason why formal steps weren't met on time of validation when package was prepared with use of NSIS tool.
2. Preparation of manifest file is a challenge to me, I have to learn it from scratch. My ideas for time being: ChatGPT support, trial and error.
3. The makeappx.exe if used with /v (verbose) switch, delivers helpful answers.

This is all for now. Initially I thought the way to publish AutoHotkey based package is well known in our community. For me, all about packaging process is new. In consequence, it means to me plenty of reading, searching, trial and error attempts. Thank you again for your support. I discovered once again that AutoHotkey help is far superior over other help files and that my reading and understanding capability is quite limited, require advancement.

Another path, which I consider, is to follow the suggestion of Descolada and give a try to MSIX Hero.

Any suggestions are welcomed. I'll share if I find something worth or if I advance with validation.

[mslonik]

Hi again,

Some reflections / conclusions after examining the third, recommended path: MSIX package preparation.

Long story short: I'm still unsuccessful. Any help is appreciated.

@Descolada: could you please share the MSIX package of AutoHotkey which you have prepared? Or maybe the manifest (XML) file itself?

---

Tools, which I've examined so far:

1. MakeAppx.exe, the official tool of Microsoft, available for free.
2. MSIX Packaging Tool, the official tool of Microsoft, available for free.
3. MSIX Hero, the third-party tool, available for free.

---

Ad. 1. MakeAppx.exe

I've created the dedicated GitHub repository, which contains several files used to prepare the Hotstrings MSIX package.

Conclusion: preparing any MSIX package is relatively straight and easy. Passing the Microsoft Store MSIX package validation is still a challenge.

What specific validation error messages do I get:

Package acceptance validation error: The following image(s) specified in the appxManifest.xml of Hotstrings.msix were not found: Assets\HotstringsLogo_100x100.png, HotstringsLogo_100x100.png, HotstringsLogo_100x100.png
Package acceptance validation error: The PublisherDisplayName element in the app manifest of Hotstrings.msix is , which doesn't match your publisher display name: Damian Damaszke Dam IT.
Package acceptance validation error: The package Hotstrings.msix must declare support for at least one language.
Package acceptance validation error: The package Hotstrings.msix specifies an unsupported default language:

The corresponding manifest file is here and below:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<Package
	xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
	xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
	>

<Identity
	Name="Hotstrings"
	ProcessorArchitecture = "x64"
	Publisher="CN=DamianDamaszkeDamIT, O=DamianDamaszkeDamIT, L=Gdańsk, S=pomorskie, C=Poland"
	Version="3.6.23.0" 
/>

  <Properties>
	<DisplayName>Hotstrings</DisplayName>
	<PublisherDisplayName>Damian Damaszke Dam IT</PublisherDisplayName>
	<Description>Text replacement software application for Microsoft Windows. Short text entered by keyboard is automatically replaced into previously defined text(s) called hotstring(s).</Description>
	<Logo>Assets\HotstringsLogo_100x100.png</Logo>
  </Properties>

<Resources>
	<Resource Language="en-US" />
</Resources>

<Applications>
	<Application 
		Id="Hotstrings"
		EntryPoint="windows.fullTrustApplication"
		Executable="Hotstrings.exe"
	>
		<uap:VisualElements 
			DisplayName="Hotstrings"
			Description="Text replacement software application for Microsoft Windows. Short text entered by keyboard is automatically replaced into previously defined text(s) called hotstring(s)."
			BackgroundColor="#FFFFFF"               
			Square150x150Logo="HotstringsLogo_100x100.png" 
			Square44x44Logo="HotstringsLogo_100x100.png" 
		>
		</uap:VisualElements>
	</Application>
</Applications>

<Dependencies>
	<!-- https://www.anoopcnair.com/windows-10-build-numbers-version-numbers/ -->
	<TargetDeviceFamily 
		Name="Windows.Desktop" 
		MinVersion="10.0.19043.985" 
		MaxVersionTested="10.0.19045.3693"
		/>
</Dependencies>  

<!-- Add additional sections and settings as needed -->

</Package>

---

Ad. 2. MSIX Packaging Tool

Surprisingly, this tool requires application installer to prepare MSIX installation package (e.g. NSIS installer). In other words, it is not able to prepare an installation package by itself. I didn't experiment much with it. I can say this tool works. What I tried is just bare package preparation. I didn't try yet combination of this tool and NSIS installer hoping for simpler, manual way of preparing the MSIX installation package.

---

Ad. 3. MSIX Hero.

The same story as above. I believe this tool is great for some tweaking / modification of existing packages, but not for creating / preparing the package from scratch.

---

Any help is appreciated. Kind regards, nickname ()

[Descolada]

@mslonik, getting started with Microsoft Store is difficult unfortunately You can expect lots of problems (and failures) with the process.

As regards to the errors you are getting, the first one is because you are missing the Assets folder with the logos, so you must create it. The other ones (eg PublisherDisplayName problem) seem like your manifest file might be broken: I recommend opening your .msix file with MSIX Packaging Tool and make the corrections in the GUI, so that the publisher name and publisher display name match what Store is expecting.

Here is a Dropbox link for an example msix package for your project, which passed Store validation once I inserted the correct package name, package display name, and publisher names using the MSIX Packaging Tool GUI. To change the publisher name I had to select "Do not sign package" under Signing preference. To test the package locally you need to install the Appx Test Root Agency certificate or sign it with your own trusted certificate.
You can also take a look at AHK v2 Store Edition unpackaged version on Github: https://github.com/Descolada/AutoHotkey-v2-Store-Edition

[mslonik]

Thank you @Descolada for prompt reply.

You've pushed me two tiny steps forward.

1. Regarding values in manifest file (XML) (Package/Identity/Name, Package/Identity/Publisher, Package/Properties/PublisherDisplayName, those are listed in Microsoft Partner Center account → Home → Apps and games → app. Name (e.g. Hotstrings) → Product Identity: https://partner.microsoft.com/en-us/dashboard/products/{app code}/identity.
2. It makes sense to install my application on virtual machine.

What tools do you use to prepare MSIX packages compatible to Microsoft Store? Is Visual Studio or only MSIX Packaging Tool? Do you sign applications with certificate?

Kind regards, mslonik()

[Descolada]

@mslonik
1. Yes, you get those values from the Product Identity page and fill them out with MSIX Packaging Tool GUI (or any other tool that does the trick).
2. You don't necessarily need to install it in a virtual machine, but I highly recommend it for easier testing. Also, you might not want to test the Windows 10 S-mode WDAC policies on your main setup.

I use MSIX Packaging Tool mainly, but also makepri.exe to generate new resource files if necessary, and MSIXHero to pack an unpacked package. If you need to constantly make modifications to the package then you can also use MakeAppX tool to install it without packaging.
When testing locally in my main setup or virtual machine, I sign my packages with the Appx Test Root Agency certificate, because it's also needed for WDAC policies. I upload to Store without certificates.

Btw, it's recommended to test your package in Windows App Certification Kit before sending it for certification, because it can identify a lot of issues beforehand.

[mslonik]

@Descolada

Thank you again for your valuable help . Without your support, I wouldn't continue this journey. Hopefully others will be able to enter Microsoft Store with AutoHotkey scripts as well.

Indeed, for the very first time, after adjusting Identity data I was able to pass automatic validation with the package which you've prepared .

I still have some quite generic questions. I noticed within the MSIX package the Assets folder. Its content corresponds to some degree with requirements described in the article Construct your Windows app's icon.

1. Do I interpret correctly that all the sizes and file names actually have been defined in this article?
2. Do you have a tool which automatically generates all required files?
3. Can you share it?

Kind regards, mslonik ()

[Descolada]

@mslonik, glad to hear you finally got it validated! Though that doesn't mean that it will pass certification. And you probably need to modify the package anyway, unless you want to explain to Store certifiers why you need it to have the capability runFullTrust.

The example package contains the minimum visual assets, namely icons of size 16x16, 24x24, 32x32, 48x48, and 256x256 (the "bare minimum" as mentioned in the article you linked). AFAIK you can reduce it even further if you remove all the scalings besides 100, but it's recommended to include the other scalings as well. You can use Visual Studio asset generator to generate them (eg create a dummy project for that), or other MSIX packaging tools often have that feature as well, for example Advanced Installer.

[mslonik]

Below is the summary of successfu submission of my application to Microsoft Store .


Goal
To publish my application written entirely in AutoHotkey to Microsoft Store. The application is called Hotstrings.
My operating system on time of writing this article is Microsoft Windows 10 Home, edition 22H2.



Why attempt to publish AutoHotkey application to Microsoft Store?

• free security certificate = no problem with application installation
• access to customers over recognizable deployment platform
• easy advertisement
• …

Requirements
How to publish application in Microsoft Store | Microsoft Learn



Solution
The path which way I've chosen ultimately: MSIX.



Acknowledgements
Huge acknowledgements to @Descolada who helped me a lot by encouraging to continue my efforts as well as by preparing example MSIX package, which next I could recreate by myself.



Disclaimer
The description below is provided "as is", without additional explanations. Use it on your own, maybe it will help you to reach the same goal. I'm not knowledgeable person in area of package authoring. Actually what I did suites to only my specific case.



Additional scripts
The additional scripts described below can be found at Hotstrings-MSIX GitHub repository.



Why MSIX?
I couldn't find clear way how to do it with EXE or MSI. From the other hand, I knew that AutoHotkey itself (the language package) was successfully published as MSIX package to Microsoft Store. The other reason behind is that for future (starting from 2026 if I recall correctly) only MSIX format will be allowed to deploy software in Microsoft Windows universe.



Structure of my application
This is important on time of assembling the MSIX package, so let me explain it in more details:

Code: Select all

C:\Users\<username>\AppData\Local\Hotstrings\
├── Languages\
│   └── English.txt
├── Libraries\
│   ├── AbbreviationsEnglish.csv
│   ├── (…)
│   └── WindowsShortcuts.csv
├── Log\
├── Config.ini
├── Hotstrings.exe
├── Hotstrings.ahk
├── HotstringsWebpage.url 
└── LICENSE_MIT 

(above picture generated thanks to tree.nathanfriend.io and https://www.ghisler.com/).

To sum up, about ~50 files, all stored in \AppData\Local folder of current user.



Tools required to proceed with packaging for Microsoft Store
Tools, which are part of Microsoft Windows SDK | Microsoft Developer, free to download:

• makepri.exe: required to prepare Package Resource Index (PRI files) required by Microsoft Store
• makeapp.exe: required to prepare MSIX package

Other tools:

• ImageMagick: Open-Source Software (OSS) required to prepare assets (sets of PNG pictures) for Microsoft Store compatible MSIX package

The installation procedure of Microsoft SDK tools:

1. Download Microsoft Windows SDK instalator (my version: 10.0.22621.0) and run it.
2. Select the following:
   • Application Verifier For Windows
   • Windows App Certification Kit
   • Windows SDK Signing Tools for Desktop Apps
   • Windows SDK for UWP Managed Apps

Estimated disk space required: 361,3 MB



info

If you ever would like to change the installation settings, go to the Settings → Apps & Features of your Windows installation. Then select `Windows SDK AddOn` and select or deselect any item.

More of the tools and how to use them:

• MakePri.exe | Microsoft Learn
• MakeAppx.exe | Microsoft Learn

Create a folder for your MSIX package
This is an important step.

Code: Select all

C:\Users\<username>\(…))\InputMSIX\
├── Assets
└── VFS\
    └── Local AppData

info

The subfolder names are required to be named as above, including the space character in between Local and AppData.

Populate VFS with files
Now I copied all the files of my application into VFS folder:

Code: Select all

C:\Users\<username>\(…))\InputMSIX\
├── Assets\
└── VFS\
    └── Local AppData\
        └── Hotstrings\
            ├── Languages\
            │   └── English.txt
            ├── Libraries\
            │   ├── AbbreviationsEnglish.csv
            │   ├── (…)
            │   └── WindowsShortcuts.csv
            ├── Log\
            ├── Config.ini
            ├── Hotstrings.exe
            ├── Hotstrings.ahk
            ├── HotstringsWebpage.url 
            └── LICENSE_MIT 

Populate Assets with files
The Assets folder must contain many files PNG (graphic) files of specific sizes and specific names. More on the required set of files you can find in the article Iconography in Windows - Windows apps | Microsoft Learn. But it is not enough. Here "the magic" starts, as not all of the required sizes are specified in that article. Also relation between filename and actual size in pixels remains a mystery for now to me. I've simply examined all the files and file sizes from the packaged authored by Descolada. The results are below.

Code: Select all

+----------------------------------------------------------+---------------+--------+
| file name                                                | size (pixels) | bits   |
+----------------------------------------------------------+---------------+--------+
| Square150x150Logo.scale-100.png                          | 150 x 150     | 32 bit |
| Square150x150Logo.scale-125.png                          | 188 x 188     | 32 bit |
| Square150x150Logo.scale-150.png                          | 225 x 225     | 32 bit |
| Square150x150Logo.scale-200.png                          | 300 x 300     | 32 bit |
| Square150x150Logo.scale-400.png                          | 600 x 600     | 32 bit |
|                                                          |               |        |
| Square44x44Logo.scale-100.png                            | 44 x 44       | 32 bit |
| Square44x44Logo.scale-125.png                            | 55 x 55       | 32 bit |
| Square44x44Logo.scale-150.png                            | 66 x 66       | 32 bit |
| Square44x44Logo.scale-200.png                            | 88 x 88       | 32 bit |
| Square44x44Logo.scale-400.png                            | 176 x 176     | 32 bit |
|                                                          |               |        |
| SplashScreen.scale-100.png                               | 620 x 300     | 32 bit |
| SplashScreen.scale-125.png                               | 775 x 375     | 32 bit |
| SplashScreen.scale-150.png                               | 930 x 450     | 32 bit |
| SplashScreen.scale-200.png                               | 1240 x 600    | 32 bit |
| SplashScreen.scale-400.png                               | 2480 x 1200   | 32 bit |
|                                                          |               |        |
| SoreLogo.scale-100.png                                   | 50 x 50       | 32 bit |
| StoreLogo.scale-125.png                                  | 63 x 63       | 32 bit |
| StoreLogo.scale-150.png                                  | 75 x 75       | 32 bit |
| StoreLogo.scale-200.png                                  | 100 x 100     | 32 bit |
| StoreLogo.scale-400.png                                  | 200 x 200     | 32 bit |
|                                                          |               |        |
| Wide310x150Logo.scale-100.png                            | 310 x 150     | 32 bit |
| Wide310x150Logo.scale-125.png                            | 388 x 188     | 32 bit |
| Wide310x150Logo.scale-150.png                            | 465 x 225     | 32 bit |
| Wide310x150Logo.scale-200.png                            | 620 x 300     | 32 bit |
| Wide310x150Logo.scale-400.png                            | 1240 x 600    | 32 bit |
|                                                          |               |        |
| Square310x310Logo.scale-100.png                          | 310 x 310     | 32 bit |
| Square310x310Logo.scale-125.png                          | 388 x 388     | 32 bit |
| Square310x310Logo.scale-150.png                          | 465 x 465     | 32 bit |
| Square310x310Logo.scale-200.png                          | 620 x 620     | 32 bit |
| Square310x310Logo.scale-400.png                          | 1240 x 1240   | 32 bit |
|                                                          |               |        |
| Square71x71Logo.scale-100.png                            | 71 x 71       | 32 bit |
| Square71x71Logo.scale-125.png                            | 89 x 89       | 32 bit |
| Square71x71Logo.scale-150.png                            | 107 x 107     | 32 bit |
| Square71x71Logo.scale-200.png                            | 142 x 142     | 32 bit |
| Square71x71Logo.scale-400.png                            | 284 x 284     | 32 bit |
|                                                          |               |        |
| Square44x44Logo.targetsize-16.png                        | 16 x 16       | 32 bit |
| Square44x44Logo.targetsize-16_altform-lightunplated.png  | 16 x 16       | 32 bit |
| quare44x44Logo.targetsize-16_altform-unplated.png        | 16 x 16       | 32 bit |
|                                                          |               |        |
| Square44x44Logo.targetsize-24.png                        | 24 x 24       | 32 bit |
| Square44x44Logo.targetsize-24_altform-lightunplated.png  | 24 x 24       | 32 bit |
| quare44x44Logo.targetsize-24_altform-unplated.png        | 24 x 24       | 32 bit |
|                                                          |               |        |
| Square44x44Logo.targetsize-32.png                        | 32 x 32       | 32 bit |
| Square44x44Logo.targetsize-32_altform-lightunplated.png  | 32 x 32       | 32 bit |
| Square44x44Logo.targetsize-32_altform-unplated.png       | 32 x 32       | 32 bit |
|                                                          |               |        |
| Square44x44Logo.targetsize-48.png                        | 48 x 48       | 32 bit |
| Square44x44Logo.targetsize-48_altform-lightunplated.png  | 48 x 48       | 32 bit |
| Square44x44Logo.targetsize-48_altform-unplated.png       | 48 x 48       | 32 bit |
|                                                          |               |        |
| Square44x44Logo.targetsize-256.png                       | 256 x 256     | 32 bit |
| Square44x44Logo.targetsize-256_altform-lightunplated.png | 256 x 256     | 32 bit |
| Square44x44Logo.targetsize-256_altform-unplated.png      | 256 x 256     | 32 bit |
+----------------------------------------------------------+---------------+--------+

note

To do: experiment with the file sizes and determine the minimum set of files.

To prepare all those files I'v written PowerShell script HotstringsMakeAssets_Pictures.ps1 which calls magick application from within ImageMagick package. Next I've moved the PNG files to the Assets folder, what is not shown in tree view.



Prepare AppManifest.xml file

Composition of the manifest file dedicated to Microsoft Store is still quite convoluted from my point of view. Information about specific sections and tags are scattered over several articles. These are which I've found useful: Generating MSIX package components - MSIX | Microsoft Learn, How to specify capabilities in a package manifest - Windows UWP applications | Microsoft Learn.

The manifest file which worked to me:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<Package 
	xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" 
	xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10" 
	xmlns:uap10="http://schemas.microsoft.com/appx/manifest/uap/windows10/10"
	xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
	IgnorableNamespaces="uap uap10 rescap"
	>

<Identity 
	Name="" 
	ProcessorArchitecture="x64" 
	Publisher="" 
	Version="3.6.23.0" 
	/>
<Properties>
	<DisplayName>Hotstrings</DisplayName>
	<PublisherDisplayName></PublisherDisplayName>
	<Description>Text replacement software application for Microsoft Windows. Short text entered by keyboard is automatically replaced into previously defined text(s) called hotstring(s).</Description>
	<Logo>Assets\StoreLogo.png</Logo>
</Properties>

<Resources>
	<Resource Language="en-US" />
    	<Resource uap:Scale="100" />
    	<Resource uap:Scale="125" />
    	<Resource uap:Scale="150" />
    	<Resource uap:Scale="200" />
    	<Resource uap:Scale="400" />
</Resources>

<Applications>
	<Application 
		EntryPoint="Windows.FullTrustApplication" 
		Executable="VFS\Local AppData\Hotstrings\Hotstrings.exe" 
		Id="Hotstrings"
		>
     <uap:VisualElements AppListEntry="default" BackgroundColor="transparent" Description="Advanced, configurable, text replacement tool written in AutoHotkey language." DisplayName="Hotstrings" Square150x150Logo="Assets\Square150x150Logo.png" Square44x44Logo="Assets\Square44x44Logo.png">
        <uap:InitialRotationPreference>
          <uap:Rotation Preference="portrait" />
          <uap:Rotation Preference="landscape" />
        </uap:InitialRotationPreference>
        <uap:DefaultTile Square310x310Logo="Assets\Square310x310Logo.png" Square71x71Logo="Assets\Square71x71Logo.png" Wide310x150Logo="Assets\Wide310x150Logo.png" />
        <uap:SplashScreen Image="Assets\SplashScreen.png" />
      </uap:VisualElements>
	</Application>
</Applications>

<Dependencies>
	<!-- https://www.anoopcnair.com/windows-10-build-numbers-version-numbers/ -->
	<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.19043.985" MaxVersionTested="10.0.19045.3693" />
</Dependencies>  

<Capabilities>
  <rescap:Capability Name="runFullTrust" />
</Capabilities>

<!-- Add additional sections and settings as needed -->

</Package>

info

Section Identity:

• Name
• Publisher

Section Properties:

• text

must be literally copied from your Microsoft Partner Center account → Home → Apps and games → app. Name (e.g. Hotstrings) → Product Identity. They are empty above on purpose.

info

Section Resources and section DisplayName: I just copied it from the reference packages prepared by Descolada.

info

Section Dependencies. See the link for details: Windows 10 Version Numbers Build Numbers Major Minor Build Rev HTMD Blog

note

To do: experiment with the file sizes and determine the minimum set of files.

Make PRI, TXT (MAP) and priconfig.xml files
General introduction to PRI files: Resource Management System - UWP applications | Microsoft Learn.
The files collected in the Assets folder now will be used to prepare the Package Resource Index (PRI) and MAP. Those files are necessary in the next steps. I've written PowerShell script HotstringsMakePRI.ps1. The output are the following files:

Code: Select all

resources.pri
resources.map.txt
resources.scale-125.pri
resources.scale-125.map.txt
resources.scale-150.pri
resources.scale-150.map.txt
resources.scale-200.pri
resources.scale-200.map.txt
resources.scale-400.pri
resources.scale-400.map.txt
priconfig.xml 

The PRI files are binary.



Make the mapping file (HotstringsMappingFile.txt)

The mapping file is necessary for the next step. I've composed it manually by merging the content of TXT files from the previous step. The outline of the HotstringsMappingFile.txt:

Code: Select all

[ResourceMetadata]
"ResourceDimensions"		"scale-100"
"ResourceDimensions"		"language-en-us"
"ResourceDimensions"		"scale-125"
"ResourceDimensions"		"scale-150"
"ResourceDimensions"		"scale-200"
"ResourceDimensions"		"scale-400"

[Files]
"(…)\Hotstrings-MSIX\PRIResources\resources.pri"					"resources.pri"
"(…)\Hotstrings-MSIX\PRIResources\resources.scale-125.pri"			"resources.scale-125.pri"
"(…)\Hotstrings-MSIX\PRIResources\resources.scale-150.pri"			"resources.scale-150.pri"
"(…)\Hotstrings-MSIX\PRIResources\resources.scale-200.pri"			"resources.scale-200.pri"
"(…)\Hotstrings-MSIX\PRIResources\resources.scale-400.pri"			"resources.scale-400.pri"
"(…)\Hotstrings-MSIX\PRIConfig\priconfig.xml"						"priconfig.xml"

"(…)\Hotstrings-MSIX\InputMSIX\Assets\Wide310x150Logo.scale-100.png"			"Assets\Wide310x150Logo.scale-100.png"
(…)
"(…)\Hotstrings-MSIX\InputMSIX\VFS\Local AppData\Hotstrings\Languages\English.txt"						"VFS\Local AppData\Hotstrings\Languages\English.txt"
(…)
"(…)\Hotstrings-MSIX\InputMSIX\VFS\Local AppData\Hotstrings\LICENSE_MIT"								"VFS\Local AppData\Hotstrings\LICENSE_MIT"

info

(…) represents part of the file path which is not crucial or the the rest of lines excluded from above listing for clarity.

Make the MSIX package
General introduction: Create an app package with the MakeAppx.exe tool - MSIX | Microsoft Learn. I'v written PowerShell script HotstringsMakeMSIXpackage.ps1 which combined the files prepared in previous steps into the MSIX file Hotstrings.msix.



Package submission
When the package was uploaded to Microsoft Partner Center (Microsoft Store submission), I received the following feedback.


warning

Package acceptance validation warning: The following restricted capabilities require approval before you can use them in your app: runFullTrust.

As a result I had to fill in manually one more window, justifying usage of restricted capabilities. Since then the above package was accepted in less than 24 hours time.



Result
Free edition of Hotstrings application in Microsoft store.

---

Kind regards, mslonik ()

[Descolada]

@mslonik congratulations! Certainly a step forward for AHK-based apps!
Hopefully the next step is getting the compiled version validated? I theorise that it would require getting it validated in Microsoft Security Intelligence, but I don't have a good app candidate to actually test it out...