I have an app that uses wyUpdate.exe to perform updates. I just call it in code and use the return value similar to how it is outlined in the silent update procedure. When I initially started integrating wyUpdate into this application, I had though I would use the AutomaticUpdater for WPF and added a reference in my application to that library. I then built the MSI using Visual Studio and installed the app on several machines (all remote).
Today I was doing some fixes on this app and realized "I don't need that reference to AutomaticUpdaterWPF anymore" and removed it, which obviously also removed the need to have AutomaticUpdaterWPF.dll in my program's install folder. I then built my update with wyBuild and left AutomaticUpdaterWPF.dll out of this version's files and as expected, when client's updated, this file was removed from their installations.
The problem I had was, with this file now gone, the next time the users tried to open the application, they got the repair dialog with the "Trying to use a resource from another location, please pick where it is now" dialog wanting them to point to the original installation MSI. Manually copying the missing dll into their install folders cleared it right up. I have since quickly rebuilt the updates including the missing file to avoid any further users from running into this issue.
Now, I realize that this is an MSI issue (as in not a wyBuild issue) and it could have been any dll that was missing. My question is, can you help me figure out how to build my MSIs so that I can remove files from the installation without causing it to want to repair it like this?
Just to clarify, I recreated the issue to get you the exact dialog that I was getting.....
"The installed product does not match the installation source(s). Until a matching source is provided or the installed product and source are synchronized, this action cannot continue.
Contact your administrator or product vendor for assistance. If there is a matching installation source, type it below or click browse to locate it."
Hey Scott,
Can you put together a simple Visual Studio project that reproduces this behavior? Send it to wyatt@wyday.com and I'll take a look at it.
Sent, thanks!
It does appear that the issue seems to lie with trying to run the application from the MSI installed shortcuts after the dll is removed. If I try to run from the executable directly, it runs.
OK, further digging has revealed that Visual Studio Deployment Package created shortcuts are not "standard" shortcuts, they are "Advertised" shortcuts. That's why the self healing attempts to take place when the user uses the MSI installed Desktop shortcut, but not when they launch with the executable directly.
I have a found a couple different ways around the shortcuts being "Advertised" (MS doesn't make it easy). I guess now the hurdle becomes on my already deployed instances of this application, how can I remove the MSI deployed shortcuts (Desktop and Start Menu) and replace them with standard shortcuts?
Replace all shortcuts in an update. That is, link the shortcuts directly to your exe files. This way you won't get that undesirable MSI behavior.
Tell me if that helps.
I will have to test that. I currently don't add Desktop shortcuts to the file list (Files & Folders -> Common Desktop) when building updates with wyBuild, and this practice does NOT cause the MSI installed shortcut to be removed. It seems that when I first started testing wyBuild, I did include a Desktop shortcut with an update and it did not replace the MSI installed one, it simply created an additional shortcut on the desktop.
I guess that's where my "how can I remove the MSI installed shortcut" portion of my question came from.
and this practice does NOT cause the MSI installed shortcut to be removed
Are the shortcuts MSI installs installed to the current user's desktop instead of the common desktop?
The MSI shortcuts are installed to the common desktop.
I have just finished putting together a test. I installed my test app with the MSI installed (common Desktop) shortcut. I created a base update package and published it which included no shortcut in the files of the update package. I then created a new update for it, including a new, standard shortcut to the common desktop in the update package (hoping it would overwrite the MSI shortcut). After the update, there was still one Desktop shortcut, however it was still the MSI installed advertised shortcut.
I think it was probably because there was no perceived change? They were both named "shortcut.lnk" in the same location, so perhaps wyUpdate saw nothing to change?
Just a further update. I started from scratch with my little test application again....
1. Build the app and install it with the MSI, which installed the Desktop shortcut. Built a base update (1.1) with wyBuiild which included all program files, but no shortcut in Common Desktop.
2. Made a slight change in the program and rebuilt. Built an incremental update with wyBuild (1.2) with all program files and this time a standard shortcut in the Common Desktop.
3. Made a slight change in the program and rebuilt. Built a 3rd incremental update with wyBuild (1.3) with all program files, and this time left the standard shortcut out again, thinking because of the difference from update 1.2 to update 1.3, maybe it would remove the MSI Desktop shortcut (because the MSI shortcut and my standard shortcut are both name "My App.lnk". After the update, the MSI Desktop shortcut lived on strong.
I really can't figure out how to get rid of this sucker. I have a feeling the same issue (self healing if a file is removed) will apply to the Start Menu shortcuts the MSI installed as well.
I'm going to look into this using that example project you sent. This is definitely a problem with the advertised shortcuts. So step 1 is to disable advertised shortcuts in your MSI installer. I'll look into how to get wyUpdate to turn advertised shortcuts into plain old vanilla shortcuts.
Awesome, thanks.
I can also confirm the same issue exists for shortcuts added to the start menu from a VS deployment project.
P.S. I found a simple little trick to disable advertised shortcuts....
1. From the UI editor of the deployment project, add a textboxes dialog. Make all textboxes hidden and then set one of the textbox properties to DISABLEADVTSHORTCUTS and its value to 1.
http://stackoverflow.com/questions/2165781/disableadvtshortcuts-1-disables-all-shortcuts
To keep my installer flow the same, I simply also deleted the "confirm installation" dialog and changed the banner text and body text of the textboxes dialog to match what the confirm text would have said.
"Confirm Installation""The Installer is ready to install MY PROJECT TITLE on your computer. Click "Next" to start the installation."
