Hi Joshua,
The objective of this specific validation was to warn user about the attempt to execute the file before it's been installed. And you are right the validation completely overlooks the uninstall scenario.
My immediate impulse was fix it by analysing the action condition and distinguishing install and uninstall scenarios. However now I am leaning towards completely removing this validation. The problem is that no condition analysis can be accurate enough as the condition can be a way more complicated than just 'NOT Installed'. In fact the combined condition can be flooded with user defined 'sub-conditions'.
> Scheduling custom actions in MSIs is clearly a great big can of worms...
Cannot agree more. That is why I introduced the simplified CLR events based model:
This relatively recent feature has also made the validation less critical.
Thank you for the feedback. I will reflect it in the next release.
The objective of this specific validation was to warn user about the attempt to execute the file before it's been installed. And you are right the validation completely overlooks the uninstall scenario.
My immediate impulse was fix it by analysing the action condition and distinguishing install and uninstall scenarios. However now I am leaning towards completely removing this validation. The problem is that no condition analysis can be accurate enough as the condition can be a way more complicated than just 'NOT Installed'. In fact the combined condition can be flooded with user defined 'sub-conditions'.
> Scheduling custom actions in MSIs is clearly a great big can of worms...
Cannot agree more. That is why I introduced the simplified CLR events based model:
project.UIInitialized += ... project.Load += ... project.BeforeInstall += ... project.AfterInstall += ...
Thank you for the feedback. I will reflect it in the next release.