Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

v14 installer?

May
12,846
164
The mess has moved to %TEMP (which doesn't seem to be a good place to leave files which are **needed** for an uninstall).
Code:
h:\temp> ffind /s *.msi
H:\temp\{1A2D0956-F6F2-4E38-BE99-19E0209ECF93}\09ECF93\tcmd.msi
H:\temp\{1A081F6D-7816-4423-B652-14F614794318}\4794318\tcmd.msi
H:\temp\{05B113D9-BB0B-460C-9788-8094C46C10CC}\46C10CC\tcmd.msi

Rex, you have managed to leave no mention in the registry of previous install source paths (good). Haven't you figured out how to remove the install source tree for the minor version just uninstalled?
 
Here the new tcmd.msi went into %TMP - do you define %TMP? The rule is supposedly to use %TMP if TMP is defined, %TEMP otherwise, for temporary files.
 
Here the new tcmd.msi went into %TMP - do you define %TMP? The rule is supposedly to use %TMP if TMP is defined, %TEMP otherwise, for temporary files.
I have them both set.

They don't belong in %TMP, %TEMP, or any place for temporary files. That MSI file is necessary for repair or uninstallation.
Code:
-> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{1A2D0956-F6F2-4E38-
BE99-19E0209ECF93}
 
        Value: InstallSource
->      Data: h:\Temp\{1A2D0956-F6F2-4E38-BE99-19E0209ECF93}\09ECF93\
 
        Value: ModifyPath
->      Data: MsiExec.exe /X{1A2D0956-F6F2-4E38-BE99-19E0209ECF93}
 
        Value: UninstallString
->      Data: MsiExec.exe /X{1A2D0956-F6F2-4E38-BE99-19E0209ECF93}
And the previous (build 21) one was not removed.
 
I now have separate directory trees containing 20 TCMD.MSI files (33 on another computer) one for each of 13.04.53 through 13.04.63 and each of 14.00.14 through 14.00.22. The only ones of any value are the two for what's actually installed (13.04.63 and 14.00.22). It's absurd, ridiculous (I don't mean to be dramatic but I can't think of better words). Apparently you think it's OK if we collect these TCMD.MSI files, one per update, FOREVER. I don't.
 
So, do what I suggested weeks ago and delete them. That would have been easier and much faster than writing a dozen emails to complain about the Windows Installer! :rolleyes:

I do not have any of those files on my system, nor (though you refuse to accept this!) do I have control over what the Windows Installer is doing on your system.
 
So, do what I suggested weeks ago and delete them. That would have been easier and much faster than writing a dozen emails to complain about the Windows Installer! :rolleyes:

I do not have any of those files on my system, nor (though you refuse to accept this!) do I have control over what the Windows Installer is doing on your system.
I believe you, and it would seem that the installer is working correctly for you. At least one other user noted a large collection of TCMD.MSI files. What about others? Please comment folks. And, can we speculate why it's not working correctly for me ... why, after updating to a new minor version, I still have the the install source (tree) from the minor version just uninstalled.
 
I just removed a few tcmd.msi from %tmp subdirectories. I agree that anything in %temp or %tmp after an installation is complete should only be junk. I had found and deleted .msi files elsewhere, too.

Whenever I install a new version or build of TCMD, SHRALIAS.EXE is already running. I have hard linked its master version into each of the TCMD installation directories, including the one where a new V14 build overwrites the previous build. The installer moves this ShrAlias.exe to \config.msi\xxxxxxxx.rbt (same drive, F: - same inode). where xxxxxxxx is the hexadecimal representation of a 32b number. After the installation is complete I manually move it back (replacing the new build's version). AFAIK the only thing changed in ShrAlias.exe over the last several versions is the version and build it reports. Rex, is it necessary?
 
I also had the issue of MSI files building up. I've never seen this with InstallShield stuff.

This is probably a flaw in Caphyon's "Advanced Installer." Rex, not all programs that build MSI installs are the same; if there are flaws in Caphyon's installer it can't necessarily be blamed on Microsoft.

With older builds, I would get MSI building in AppData\Roaming. I pointed out that the *roaming* portion of a *user's* profile is definitely not the right place to keep MSI files around for purpose of repair/uninstall. Something must have changed a few builds back because I don't get MSI files there any more.

I am not sure if they are being stored in %TEMP%. I regularly clear that out so if they were there, they are now gone. I will have to try and take note the next time I install.
 
I do not have any of those files on my system, nor (though you refuse to accept this!) do I have control over what the Windows Installer is doing on your system.
Am I to interpret that as "Upgrading from build 22 to build 23 **should** remove the installation source for build 22"?
A couple days ago I cleaned my system of all installation sources except those mentioned in the registry. That left me with one for v13b63 and one for v14b22. Last night I upgraded v14 from b22 to b23. I still have the installation source for b22.
Code:
h:\temp> ffind /s *.msi
H:\temp\{1A2D0956-F6F2-4E38-BE99-19E0209ECF93}\09ECF93\tcmd.msi
H:\temp\{2EC2749A-9803-46A2-898A-9E67B6E37AC0}\6E37AC0\tcmd.msi
Please help me determine what's wrong with my system.
If I haven't said so before, I agree with others that (1) these files, needed for repair/uninstall, don't belong in %TEMP and (2) other installer software do not seem to have this problem that Caphyon has.
 
At least one other user noted a large collection of TCMD.MSI files. What about others? Please comment folks.
I found 16 TCMD.msi files. One is located under %TEMP and it's for TCMD 14.00.021 (latest version on my system). The other 15 files are located under "AppData\Roaming\JP Software" and correspond to various subversions of TCMD 13.03, 13.04 and 14.00.
 

Similar threads

Back
Top