Good day -

I have installed this latest ATE on a few PCs and have experienced the same result: http://www.microsabio.net/dist/65dev/ate/ate-6.5.1726.0-web-upd.exe

When launching it warns that you are updating from version x to version y. Good so far. However it then says that it cannot locate the current version location. Seems odd since it detected it to begin with! It then wants to install into a default dir of C:\ATE. We use a custom location of C:\EDGEMED which if you override it will continue the install to the desired location. I just don't trust the average user to now clobber their setup and wind up with 2 ATE installs on their PC.

Not urgent as we are not "adverstising" this version, only deploying it as needed.

TIA

The installer gets the prior version from the Registry, not by examining the actual EXE on disk, so that explains how there could be a disconnect there.

As for wanting to install into the default location instead of your prior custom location, did you launch it from the Help > Check for Updates menu? Or just by clicking on the link? If the latter, can you verify whether the former works as expected? (It will say you've already got the latest version, but still give you the option to re-run the install in 'Repair' mode.)

Hey - i just clicked on the actual link from the /dist folder.

Our Help > Check for Updates is not updated to point to this latest version yet sorry, so i cannot test this feature.

The plot thickens. I forgot that you have your own custom distribution folder. I can't remember though whether your installer package was also custom, or you just wanted to maintain your own standard update repository independent of the global one.

I can replace your 6.5.1672.0 version with the latest installer, but that would then become immediately available to all of your end users. Alternatively we can create a new distribution folder, but then you'll have to update the ateupdloc.cfg file on all your sites to redirect them to the new version. We may want to move this conversation to email as we're starting to get into the weeds.

Sure thing - when we have vetted out this latest flavor we can discuss getting it over to our custom install area...

I just thought it was odd that in general ATE didn't know where the existing installation of ATE lives on the workstation! Surely were not the only ones that doesn't use C:\ATE as the install directory... (or are we?)

I'm not sure where people install it. But I think the confusion arises when you run the installer directly without any switches. When you run it from the Check for Updates menu it uses different logic. It's also possible that if you install it in multiple places (which sounds like it may have happened), it only keeps track of the last one.

OK so i am going to beat the dead horse here...

There is a flaw in the install logic when running the installer from scratch off your web site. You shouldn't need to update ATE from the "Check for Updates utility". And why would a direct link installation from the /dist page require switches? It should find the current installation and overlay it no matter how the installer launches. Happened on 3 separate pcs with same MO. Again since i am driving i know where to install it but an end user will be lost.

Again no rush as we are not actively deploying this flavor but i still believe there is an issue.

I think what has happened here is that we created a custom installer for you. Among other differences from the standard version (target location, startup configuration file, etc.) it has a distinct internal ID from the standard installer, which is why it isn't connecting to the prior location.

I checked with Ty, who has his own preferred customer install location, and he says the standard installer finds and uses his custom location without any difficulty. So I don't think that's the issue.

I'm not sure of the GUID of the installer you've been using previously, though I suspect it is {616ADAB0-9035-11E2-3D6C-0D8FC4204AE1} . You may want to search your Registry for that string to see if it leads to a something like this:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{616ADAB0-9035-11E2-3D6C-0D8FC4204AE1}

containing a data item InstallLocation set to C:\edgeMED. In that case, we could probably recreate an updated custom installer for your base. We'll probably have to do that in any case if you want to do a proper complete update of your customer base. You could do a workaround by adding the switch /X c:\edgeMED to the ate-6.5.xxxx.x-web-upd.exe command, but you have to then launch it from your app (custom command line) rather than having users to go to the web or the Check for Updates menu. I'm not sure it's practical to have the standard installer look for several variations of custom installation IDs. And even if it did, the standard installer wouldn't work for any of your new installs.

I guess these are the kinds of details not fully considered when making the fateful decision to go off the reservation. Windows installers have gotten to be more complicated than most of the apps they're installing, which is one reason why you don't see many installers give you a choice about location. Typically it's not that difficult to build an install package (assuming you start with one of the many toolkits), but it gets rapidly more difficult to handle all the variations that arise with a heterogeneous base (versions, locations, security levels, architectures, updating configurations while retaining local options, ...)

Understood. Thank you.