Shortcuts based on $UNINSTALLLINK$ no longer works in X2

[spicymikey]

I have a technique of creating shortcuts for customers that point to the setup.exe with command line switches for quick access to certain features. This gives quick access to launch my setup again for checking on automatic web updater and a few other things. it all worked great in the version before x2, but not with X2 and these same installers.

Now, when I install the package, I get Windows errors saying the item the shortcut refers to has been moved, as well as IA errors saying the shortcut is bad with a button of "Fix it", "Delete It", or "Cancel".

I saw a posting that got me excited and hoped it would solve my issue. But this post was about uninstalling. Seems similar. But for me it happens when installing and trying to create the shortcuts as well as on uninstalling.
viewtopic.php?f=2&t=10016

Investigating a bit further I think I see whats happening but don't know the work around. Seems the UNINSTALLLINK variable is pointing to some temporary location in ProgramData for the install files rather than the Windows MSI location. By the time it comes to setup the shortcuts, that directory is empty. This happens with Caching turned on always, and default method. Neither worked.

Any ideas on either how to get this technique to work like the previious v11 would be appreciated. If there is a better way to do it in x2, that would be fine also.

thanks

[spicymikey]

Here's what seems to be the cause and solution. After much testing I discovered that the "create shortcut" code is placed too early in the script. Not sure if I hand coded it that way, or if the older IA engines did it by default. However, it won't work reliably anymore with X2 because the cache isn't necessarily created yet when some of those commands execute.

Solution: Place any shortcuts which reference $UNINSTALLLINK$ after the Apply command where you would normally put post install activity. if you do that, the setup.exe will be reliably already created and the shortcuts will be created like they were before X2

Hope that helps others who might stumble on this one also.

[FrancescoT]

Dear Spicymikey,

I suppose that your setup is based on NATIVE ENGINE, due the fact that you are able to create a shortcut after Apply Install execution. Unless you are forcing NATIVE ENGINE capabilities to make possible the shortcut creation during post install activity.

Anyway, I am not able to replicate the same for what concerns the UNINSTALLLINK reference. During my tests the pre-defined variable correctly holds the full path of the un-installation setup program and this regardless of the used engine.

I just created a new project from scratch to verify the variable value... using the latest IA X2 version available (19.08).

Regards

[spicymikey]

Hi Francesco

No I am not using the Native Engine. And, no I was wrong, that didn't solve the problem. I jumped the gun on my post. The errors stopped occurring because the shortcuts were no longer being created Stupid me.

At any rate, I'm back to where I started. The UNINSTALLLINK variable contains the correct location. The problem is that the setup.exe doesn't seem to be there yet. We are talking about a race condition of some kind which makes it work sometimes and not work other times. it only started happening with X2 and I'm using the latest build.

Can you think of any settings I might have wrong to cause this? I checked the "Always Cache" option but that didn't help. Out of ideas?

[FrancescoT]

Really strange!

A question, did you use a re-generated license file to activate the latest trial?

Regards

[spicymikey]

Yes. I think I'm on the latest build. The Version screen says x2 12.1.14. IS there a fix to this issue in a never version?

Also, what does delayuntil_applychanges do for non native engine installs. Would that help in any way?

Thanks
Mike

[spicymikey]

Francesco

Here's a good clue. I tested this 3 times for cause and effect. It worked each time. it seems this problem only occurs if I try to use one of your "Pin Shortcut To" checkboxes along with a shortcut that uses the UNINSTALLLINK variable for the "Shortcut To" field. Windows will throw an error saying the shortcut cannot be created and offering to let the user browse for it or cancel. This popup doesn't stop the Install and it continues on. So if you wait a few seconds, click Browse, it will bring you to the ProgramData folder and the setup.exe program will indeed now be there. You can then select it and create the shortcut by hand. Needless to say, that won't work for a professional experience, and I really would like to take advantage of these newer options to pin tiles to the start screen for Win8.x.

So, first off, can you try this yourself and confirm it happens for you with those simple rules (shortcut using UNINSTALLLINK with "Pin Shortcut To Start Screen"). If its true, I'm hoping you can suggest a work around and/or create a new Build that can address this.

[FrancescoT]

Dear Spicymikey,

I just tested with creating a shortcut using UNINSTALLLINK with "Pin Shortcut To Start Screen" option ... but I am not able to see the problems you are reporting. For what I see, the pre-defined variable correctly holds the uninstall path.

unInstallLink.png (142.1 KiB) Viewed 11362 times

Could you please try to post a very simple project that replicates the issue? ...Maybe I am not following the same steps you used.
Unfortunately, without knowing the cause it's quite difficult to share a possible suggestion.

For what concerns my previous question, you should check the installed version in "Add Remove Program" under control panel.

Each InstallAware version (including updates) requires a specific personal license file to activate the product.

PLEASE NOTE!
Using different versions of license installers and trial version can wreak havoc with the IDE and the setup engine. Out-of-sync versions will cause a lot of random issues with your setups purely due to engine/compiler/script version mismatches and cannot be supported by technical support.

Regards

[spicymikey]

Hi Francesco

I think you are missing one subtle detail. it's NOT that the variable does not contain the location name. it does. The problem is your installer is trying to create the shortcut at a point in the setup where your installer has NOT written the setup.exe to that location. Therefore, Windows is throwing up an error saying the shortcut cannot be created. it's a timing issue. Let me see if I can create a stripped down version for you and share it with you. This installer is very complex so maybe removing all the files and assemblies, etc. will affect the timing and it will work. However, that won't be a solution of course.

I will get back to you. Hopefully a simplified version of my installer will cause the timing issue as well and you can help debug it easier

Thanks

[FrancescoT]

Dear Spicymikey,

the fact is that I am not receiving any error ... during my test the shortcut is created correctly.

Anyway, you may try to create a test project from scratch.

Let me know.

Regards

[spicymikey]

Hi Francesco

So I did what you said (sort of). I didn't create a brand new project, but instead took the existing project and stripped out all the includes and any commands that install files, assemblies, etc. I even removed the webupdator logic at the end to setup for automatically checking for updates. All that is left now is the code that runs the show. I still get errors from Windows saying the setup.exe is not in programdata if I have those options checked. I opened the progamdata folder on my desktop and watched with my own eyes that the setup.exe and the associated mia files are not written to that programdata folder until just about the end. The shortcuts are created earlier, thus the problem creating a shortcut pointing to $UNINSTALLLINK$

I'm inclined to offer this project to you to try it there and see if there might be some setting (or combination of settings) causing this. But before I did that, you repeated your concern that I might have a mismatch of installaware components which would cause unpredictable results. How could I check that. The splash screen says I am on Build 12.1.14

Also, keep in mind this project was upgraded from the prior version. These project files are binary. Even the code. Is there any chance that could be an issue? I haven't tried to create a NEW project from scratch because I'm certain that will work since you already tested it. There's probably something either wrong in my combination of settings I have configured, or the upgrade may not have worked and a corruption is causing this subtle issue. I still think its the first option and hopefully if you get the project you will spot it and we can all learn something. It's fairly small now with most things cut out

Thanks

[FrancescoT]

Dear Spicymikey,

if you were using the latest IA X2 version or if your activation were properly synchronized with the latest version, the build number reported with the version splash screen (from IA IDE) should be "4.03.15" and "19.08" for the version number under control panel.

I suggest you to un-install your current version, then download and install the latest trial and activate it using a new re-generated license file.

In case your problem still persists, please send your project as compressed archive to: support@installaware.com .

Regards

[spicymikey]

Francesco,

I uninstalled and reinstalled IAX2 from scratch. Generated a new license key also. The version number did indeed change. I was hopeful that would solve it. But it didn't. Exact same issue. I'm going to send you this project via email. Would you please take a look at it and see if you spot anything.

Again, I see the shortcut getting created somewhere during the setup process. But the exe and dll's cached to the programdata folder for the installer do not get written until the "Finished" dialog box displays when the setup is completing. If there's a way to control when the shortcuts get created that would solve the issue, but I don't seem to have control over that.

Mike

[spicymikey]

*** RESOLVED ***

So this was a tough one and Francesco took it offline with me for a week while we tracked it down. Bottom line; There is indeed a timing issue related to using the MSI installer that will not occur with the Native Installer. if you are using MSI then using this nice new feature in X2 to pin shortcuts that point to $UNINSTALLLINK$ will indeed fail. Reason is because the Setup.exe file and all the cache files are not written to the disk until the very end of the process.

Workaround: Create a temporary/dummy setup.exe before the installer starts using some custom code that Francesco gave me. This code (below) will create that dummy file for you in the ENGINECACHE location so the shortcut creation will not fail. At the end of the install, that dummy file will be replaced with the real one by the MSI engine.

In this code there is a hardcoding of the name for my setup exe (SL_SETUP_V10_0). If you use a standard setup name you can use $TITLE$ in place of hardcoding OR you can create a compiler variable to hold the name.

~InstallAware Clipboard Data~
~Set Variable~
~{52427090-7C36-480D-99B6-C3C2438D6EAD}~
~NATIVE_ENGINE$MYAH$MYAH$FALSE~
~FALSE~
~Call DLL Function~
~{19FB4ECD-54E6-4A56-B49A-99C103592D80}~
~Kernel32.dll,CopyFileW,bool,,"pointer to UNICODE string",$SUPPORTDIR$SL_Setup_v10_0.msi,"pointer to UNICODE string",$UNINSTALLLINK$,bool,FALSE,$~
~mIDEFunc.dll\mEXEFunc.dll~
~Create Folder~
~{4D715661-4FFE-4C2E-8549-5917A7B8A588}~
~$ENGINECACHE$~
~Set Variable~
~{D164DA21-2616-434F-B7F0-5F2C9EDFF3F8}~
~NATIVE_ENGINE$MYAH$MYAH$FALSE~
~TRUE~