kkkwj
Posts: 88
Joined: Thu Mar 01, 2007 10:45 pm

Registry keys are not being created by default

Mon Jan 30, 2023 12:44 am

I am trying to get the updater working on my app to move from version 1.0.0 to 2.0.0. It has been a long process, at least several days in length. I am fighting inadequate documentation, confusing fields, inadequate tutorials, and inadequate C# example code (sigh). There are *years* of forum questions on the same topic. Here is my question to add to the list. :-)

I finally got the updates working okay by pointing the app installer (Updater field in the aip project) to the dev UpdateConfig.txt file created by the Update.aip project. The Update.aip project also pointed to the .msi file generated by the AppInstall.aip project. The /silent option in the code seemed to work okay, but the frequency check for updates value of 2 days was a *constant*, irritating hassle. I could find no documentation to disable the check (0 days did not work). Eventually I found -nofreqcheck in the forum, but that conflicted with the advice that the /silent option had to be alone. Anyhow, my point here is that at one point, the update process worked.

(Oh, PS, in the C# example code, there is an undocumented delay of 10 seconds for the update dialog thread. Why? I eventually guessed it was to prevent the app dialog from covering up the updater dialog. Is that the reason.)

Of course, getting updates working in my dev environment is pretty useless, so I next tried to check for update files on a network drive so that multiple machines (including mine) could check for updates. I have had nothing but failures for most of the day. Error: "The update file size does not match the configuration size." Yet when I check the sizes using 'dir' in a Command Window, the disk sizes match exactly. I have attached a screenshot of the almost useless error message. The software has its hands on the filenames, pathnames, and file sizes - why doesn't it print the values in the error message to be specific and point me to the error? Why do I have to guess? What files exactly is it reading? What sizes exactly is it seeing? Frustrating! I love you guys and AI, but you could easily do better.
ai error dialog.jpg
This dialog was frustrating because it did not provide any useful (actionable, comparative) information.
ai error dialog.jpg (97.77KiB)Viewed 8209 times
Q1. Can I use "-nofreqcheck /silent" in the code from the C# example?

Code: Select all

 static void StartSilent() {
    // The delay lets the application boot first to put the updater app on top
    // of the application window
    Thread.Sleep(4000);
    var process = Process.Start(UpdaterModulePath, " /silent");
    process.Close();
  }


Q2. Does "Publisher" in the Product Definition turn into Manufacturer in the registry keys that are created by default on every install? No registry keys are being created by my project - do I have to do something special to get them created so the updater can reference them?

Q3. The AppUpdate.aip Update installed Detection screen uses HKUD\Software, not HKCU or HKLM (which are not greyed out in the Registry section). Exactly which keys are created by default? Exactly what do I need to do to create keys for the updater to use (HKUD)? The documentation is not good, and should be improved, IMHO. I think I must have gone through 10 or 12 pages to try to get updates working because no single page or tutorial told the whole *working* procedure. I have spent DAYS trying to get things to work, and I am stalled on using a simple network drive (sigh).
ai updater registry.jpg
HKUD is not the combined Current user/Local Machine shown in the Registry section.
ai updater registry.jpg (59.15KiB)Viewed 8209 times
Thank you.

kkkwj
Posts: 88
Joined: Thu Mar 01, 2007 10:45 pm

Re: Registry keys are not being created by default

Tue Jan 31, 2023 1:11 am

I found an old post from 2013 ten years ago that said that "on a 64 bit system, where a 32-bit package is installed, the registry keys are stored in the WOW6432node." I'm running win11/x64 and my AI project installs a 32bit package by deafult. But it is not creating the registry version key in that node either.

How can I get the upgrader to compare incoming and installed versions using the registry if the installer does not create registry keys by default. Do I somehow need to turn on the keys shown in the Common User/Local Machine tree branch? The documentation is definitely not helpful in this regard.

Should I even be using the registry for the updater? What is the recommended method?

kkkwj
Posts: 88
Joined: Thu Mar 01, 2007 10:45 pm

Re: Registry keys are not being created by default

Tue Jan 31, 2023 7:28 am

I started my project completely over with a fresh aip file. My theory is that the old file was corrupted somehow when I removed the MSIX build that was in the same project as the MSI build.

I created a new MSI build installer, and (to make a long story short), eventually found the product keys in the HKCU\Software\WOW6432Node. The installer (by default) builds a 32bit package, but I only intend to install on win10/11 64bit machines running NET 6 at least.

Q1. Are the current settings the recommended practice for my scenario?

Q2. Should I be forcing a 64 bit package to force the registry keys out of the WOW6432Node into the normal tree locations?

Q3. If I do that, do I have to make a corresponding change in the updater project and configuration file to find the relocated registry keys?

Thank you.

Catalin
Posts: 6542
Joined: Wed Jun 13, 2018 7:49 am

Re: Registry keys are not being created by default

Wed Feb 01, 2023 2:15 pm

Hello,
I am fighting inadequate documentation, confusing fields, inadequate tutorials, and inadequate C# example code (sigh).
We have a video which explains how to achieve this, step-by-step.

Enable and configure automatic updates for a Windows application

I don't think you can go wrong with this video. :)
but the frequency check for updates value of 2 days was a *constant*, irritating hassle. I could find no documentation to disable the check (0 days did not work). Eventually I found -nofreqcheck in the forum, but that conflicted with the advice that the /silent option had to be alone. Anyhow, my point here is that at one point, the update process worked.
In our "Update Behavior" article, you can see that if the "Use check frequency" option is disabled, then the check should be skipped.
Anyhow, my point here is that at one point, the update process worked.
I'm glad you managed to get this working! :)
I created a new MSI build installer, and (to make a long story short), eventually found the product keys in the HKCU\Software\WOW6432Node. The installer (by default) builds a 32bit package, but I only intend to install on win10/11 64bit machines running NET 6 at least.
Those registry entries are created by default in each Advanced Installer project. It's the minimum required to recognize your setup in case of an upgrade.
Screenshot_59.png
Screenshot_59.png (16.68KiB)Viewed 6101 times

In your case, the registries are created under the HKCU hive because, most likely, your installation is set to "Per-user" in the "Install Parameters" page.

The HKUD under the "Installed Detection Criteria" tab is:
The default search uses HKUD registry hive, which makes the Updater check both HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE. If you want to check only a specific hive you can use HKCU for HKEY_CURRENT_USER and HKLM for HKEY_LOCAL_MACHINE.
Q1. Are the current settings the recommended practice for my scenario?
Yes, there is no issue with installing per-user. However, only the user will be able to update.
Q2. Should I be forcing a 64 bit package to force the registry keys out of the WOW6432Node into the normal tree locations?
Not really, unless you are sure your setup will only be installed on 64-bit machines.

A 32-bit setup can be installed on a 64-bit machine, but a 64-bit setup can not be installed on a 32-bit machine.

That being said, it is up to you, depending on your scenario.
Q3. If I do that, do I have to make a corresponding change in the updater project and configuration file to find the relocated registry keys?
Yes, under the "Installed Detection Criteria" tab, you would need to check the "64-bit" option.
Screenshot_60.png
Screenshot_60.png (23.95KiB)Viewed 6101 times

Hope this helps!

Best regards,
Catalin
Catalin Gheorghe - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube

kkkwj
Posts: 88
Joined: Thu Mar 01, 2007 10:45 pm

Re: Registry keys are not being created by default

Mon Feb 06, 2023 7:03 pm

I figured out that I needed to select '64 bit AMD' in the dropdown in the application aip file, and check the 64-bit registry option in the updater.aip file (as you described above). Then the registry keys show up in the "normal" (more visible) place. This ticket can be closed.

Catalin
Posts: 6542
Joined: Wed Jun 13, 2018 7:49 am

Re: Registry keys are not being created by default

Tue Feb 07, 2023 10:13 am

Hello,

I'm glad you got this working.

Best regards,
Catalin
Catalin Gheorghe - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube

Return to “Common Problems”