Actually, it does. I've found that if .NET 3.5 SP1 (which is what we required before) is not installed on a machine, and we install .NET 4.0, the operating system will require the WIC component. ... View more

Your best bet might be to use an InstallScript project, so that the wrapper project isn't registered on the machine as a Windows Installer application. We've done something similar (although ours will install, uninstall or modify a suite of products). We put any customer input required in OnFirstUIBefore, and used OnFirstUIAfter to simply run the other executables or MSI files. We also set up the InstallScript product so that it always installs as though it were the first time, and handled upgrades by detecting if the embedded project is present and running the current installation with the appropriate command line switches to the MSI. (We do display a dialog in that case to detemine if we should upgrade or uninstall.) Good luck! ... View more

Unfortunately, no, not that I've found. ... View more

I don't think you can do that. Take a look at the Windows Installer documentation for the KeyPath column in the Components table. (From the IS IDE, go to the Direct Editor, select the Components table, click in it and hit F1). Could you install those files by embedding them in an exe that is run from a custom action in your install? Then Windows Installer won't know anything about them, and removing them won't trigger a repair. (Of course, you'll have to handle rollback, uninstallation and upgrade from custom actions as well.) ... View more

As I meant to say, you can't really turn OFF the Windows Installer functionality that repairs installs with missing components. Is there a reason you want to remove files installed with your application? Could you serve your purpose by making the installation of the files conditional in some way? If you are installing components with a keypath of a folder, you should be able to delete the files but leave the folder, and repair shouldn't be triggered. (I think.) Good luck. ... View more

As I understand it, every component has a keypath for Windows Installer. If it is not a file name, then I think it defaults to the folder the file is in. Is your application deleting folders? I don't think there is any way to actually turn on the Installer functionality that repairs if it finds missing components. What you might do is turn on automatic logging on the machine and see what Windows Installer is checking that triggers the repair. (Registry key: HKLM->Software\Policies\Microsoft\Windows\Installer; name "Logging", value "voicewarmup") ... View more

You might want to search these forums and the IS HelpNet for information about using dynamic linking. In general, though, the way IS handles dynamic linking (in MSIs) is to create a component for each folder or subfolder, since the Windows Installer can install a component's contents only to one folder. IS then generates a GUID for each of those components. I don't know the reason, exactly, but IS doesn't seem to be able to synch GUIDs for components for minor upgrades when the dynamic link is more than one folder "deep". From what I have seen in these forums (and in my experience) you will have issues with minor updates if you have dynamic links that include subfolders. You would be better off either creating a component for each subfolder, or using major upgrades (uninstall, then reinstall) if you use dynamic links with subfolders. ... View more

Unfortunately, I haven't found a way to do that yet. I've been thinking of getting rid of my entries in the MSI tables and trying to handle things through a custom action, by checking to see if the uninstall is from a major upgrade and not uninstalling the service if true. Haven't had a chance to see if this would work though. I'd be interested in hearing if you come up with any solutions! ... View more

Be sure to search this forum and the IS HelpNet for issues using Dynamic Linking. It is very convenient, but has definite ramifications if you want to do minor updates later. ... View more

Have you looked at a log file to determine where it is getting changed? If you look at the AppSearch action you should be able to tell if is being retrieved properly, and if you do a search on that property name you should be able to see if it is getting re-written somewhere. I assume you are using IS XML handling; if the property is being retrieved properly and not being changed by Windows Installer, then it must be the IS XML dll that is doing it and you'll have to go to their Support people to find out if you can prevent it. (Or write your own dll to do the XML handling...) ... View more

I'm a little confused. Are you saying that the value returned in the AppSearch is modified? Or is the value getting modified later throught some other action? ... View more

You may be able to override the version numbers so that your minor upgrade will work. Right-click on the individual file name in the Files View, click properties, and enter a higher version number. The MSI will build with the higher number so that the comparison will be "tricked" into thinking it has a higher version and should replace it. This isn't the "best practice" (you should change the version number for newer versioned files), but it may help you get around your issue. ... View more

Basic MSI has a standard custom action (type 19) that will display a message and abort; you wouldn't need to use InstallScript to accomplish that. ... View more

Or set up your own searches on the registry keys using the AppSearch table, which shows up in the System Search view. ... View more

Check further in the log, around RemoveExistingProducts, to see if it tells you anything else. One reason I can think of offhand is if the product was originally installed per-machine and the upgrade is running per-user. ... View more