Updater says invalid file

[kkkwj]

I had updates working properly for my simple MSI v1.00 -> v2.00 projects, using first the filesystem and later a web server. So this is a puzzle to me.

The updater /checknow tries to read the AppUpdate.txt file from the web server and then complains that the file is invalid, missing, or that the contents are invalid.

BUT ...
- I verified the v1.00 project contains the correct URL, by eyeball and by copy/pasting the URL from the web server.
- I verified the URL of the MSI file inside the Update.txt file is correct by pasting it into a browser to download the correct file.
- I verified the file byte size in the Update.txt file matches the file byte size on my disk.
- I verified that ';aiu;' is the first string in the updates file on the server (copied directly from my disk)

I carefully
- Rebuilt the v2.00 msi file
- Pointed the AppUpdatev2.00.aip updater project to the new v2.00 msi file
- Rebuilt the Update.txt file to get new checksums, etc.
- Checked all the URLs in the Update.txt file too.

But the updater, called from the v1.00 app, goes to the web and claims that the file is missing, invalid, has a bad ;aiu; string, or has other bad information!

I am at the end of my rope. It shouldn't be this hard. The updater.exe file should have more brains and precision - it should tell me EXACTLY what it thinks went wrong. Which field, exactly? What does it see that doesn't match, exactly? Which filename/URL was it using, EXACTLY?

I've spent half a day at least trying to get the updater to work with no success. It's a big waste of time, IMHO, since your programmers could easily have produced a better error message - they have code that knows EXACTLY what went wrong.

Q. Do you have any ideas about how I can debug the problem further and get the updates working again? Thank you.

ai bad updater file.jpg (32.41 KiB) Viewed 12867 times

[kkkwj]

I created new AI projects for v1, v2, and v2Updater. I was careful to use *exactly* the same settings from all the old projects.
- The updater worked fine with the new files
- The apps did NOT install side-by-side (the correct thing to do)

My conclusion is that the AI software has bugs in it that do the wrong thing (or more likely, omit the right things) when the project types are changed. I have run into this issue multiple times as a newbie as I progress through the types MSI (default), to MSIX, to EXE with preinstall prereqs, and back to MSI.

I am certain of this because the defects have wasted huge amounts of time (days) every time I experiment and change the project type. I wish I had saved all the relevant AIP project files for you, but I did not. It happened when:
- changing my early MSIs to MSIX
- adding a second MSIX build to my MSI project
- removing the MSIX from the joint project
- changing MSI to EXE and back
- and most recently, when switching my simple 1) EXE/preinstall NET 6 project to 2) EXE with featured-based NET 6 prerequisite, and then to MSI with feature-based NET 6 prerequisite.

As time goes by, I am learning to:

1) NEVER switch my project type, and

2) if I ever do change the type, do NOT spend time trying to debug side-by-side installs when the Product IDs are obviously different (Update GUIDs are identical because I copy v1.aip to v2.aip and change the Product ID and generate a new Product GUID). Instead, create new projects from scratch as early as possible to avoid wasting time.

I wish I had saved all the files so that I could back up my claim and make them reproducible for you, but I did not. I am posting this here just to increase your awareness about the issue, not because I expect you to waste time trying to hunt down the issues and fix them.

If it were my company (I used to run a company with 25 programmers), I would instruct the devs or testers to make a matrix of all possible project switches (like I listed above) and test a simple v1->v2 upgrade process to detect side by side installs, updater.exe rejecting the Update.txt file (this ticket), improving the rejection error messages (state EXACTLY why the Update.txt file was being rejected), and see which project file attributes changed or did not change after the switch of product types.

I would also ask for specific answers about how side-by-side installs could occur when the Update GUIDs were visually the same and the Product GUIDs were obviously different. (This situation happened to me on this ticket.)

Anyhow, recreating everything from scratch has me up and running again with my simple v1->v2 upgrade process. And my lesson to myself is ... write on the blackboard 10 times:
- I will always create new project files instead of changing the product type (MSI, EXE, MSIX, etc).
- I will always create new project files instead of changing the product type (MSI, EXE, MSIX, etc).
- I will always create new project files instead of changing the product type (MSI, EXE, MSIX, etc).
...

[kkkwj]

To try to help you investigate (I'm hoping you will), I have attached
- a Failure Notes.txt file
- the v1, v2, and v2Update.aip files that protested a malformed Update.txt file on the web and did a side-by-side installation
- the new created-from-scratch v1 and v2 files that worked instantly.
- AFAIK, I used the same v2Update.aip project file for both scenarios.

Good luck!

Failure notes.txt

Notes giving some history

(2.17 KiB) Downloaded 526 times

HsLicenseServer v1.00 old.aip

protested malformed Update.txt file and did a side-by-side installation.

(34.66 KiB) Downloaded 919 times

HsLicenseServer v2.00 old.aip

protested malformed Update.txt file and did a side-by-side installation.

(34.66 KiB) Downloaded 435 times

[kkkwj]

More files.

HsLicenseServerUpdate old.txt

(659 Bytes) Downloaded 1140 times

works HsLicenseServer v1.00.aip

(34.2 KiB) Downloaded 1060 times

works HsLicenseServer v2.00.aip

(34.31 KiB) Downloaded 1084 times

[kkkwj]

And more files.

works HsLicenseServerUpdate v2.00.aip

(1.94 KiB) Downloaded 1078 times

works HsLicenseServerUpdate.txt

(671 Bytes) Downloaded 1140 times

[Liviu]

Hello,

Usually, the "Checking for Updates - Invalid or missing updates configuration file. The first line of the .INI file should be ";aiu;". Its possible that the content on the server does not match the updates configuration file URL" error may happen if the URL, set in the "Updates Configuration File URL" field from "Updater" page, doesn't point to your INI file hosted on your server. In order to check this you can try to open the URL set in the "Updates Configuration File URL" field in an Internet browser.

As I can see, you are using the Updater for local deployment. A similar issue was disccused on the Updater not working as expected forum thread. Please have a look on it.

I think you may be missing some steps from the updater process (local deployment), but I do not see any Updates Configuration Project attached.

Anyway, you mentioned that you already got this working.

It is unlikely that changing the build type caused this error. It is more probable that the error resulted from the inability to access the local file.

Let us know if you have any questions.

Best regards,
Liviu

[kkkwj]

Hi Liviu, thank you for your response.

I know that I had not changed the URL or file location for the updater file. They had been unchanged for days.

Something weird happened in the project file(s), so eventually, I just abandoned them and recreated them from scratch. That fixed the issue immediately. My lessons were that I should 1) never change the product type MSI/EXE after creating a project, and 2) be prepared to delete and recreate misbehaving project files sooner rather than later.

[Catalin]

Hello,

Thank you for your followup on this!

We are glad everything is working as expected now.

Best regards,
Catalin