I am having a similar issue. When trying to publish an uninstall script I get unable to validate the execuable. I realize this is probably a good thing to protect my environment but my script is harmless, how can I validate it?
First, regarding your '2010' uninstaller -- it sounds to me like the package is getting to the client, and executing, but either not doing anything, or failing. If the uninstaller has any logging capability, you might be able to get additional feedback from verbose logging. Also, double-check the return codes you've defined in the <program> element that declares the uninstaller.
Uninstalling the previous version in the <preexecution> section is the appropriate place to do this task.
Another way to approach this is packaging the uninstaller as its own separate package, rather than implementing it via PackageBoot. PackageBoot is a great way to do downlevel product uninstallations, particularly if they're MSI based and you only need to provide the ProductID, but for scripts or EXE packages, it can get a bit more complex.
Neither superseded nor bundled scenarios would be appropriate for this task.
The superseded option allows you to define a previously existing package that you now want the Windows Update Agent to universally ignore, because a newer package has been declared.
The bundled option is designed to allow two separate independent packages (i.e. Firefox and the Flash PlugIn) to be treated by the Windows Update Agent as a composite set of updates. In this scenario, if neither were installed on a system, both would be installed. If only one is present, the other would be installed. The end result is that when the 'package' is reported as Installed, you know that both that version of Firefox AND that version of the Flash PlugIn have been installed.
It is not possible to link one package to another, except to the extent that you can tie pre-execution or post-execution steps in PackageBoot to a single package.
> When trying to publish an uninstall script I get unable to validate the executable
If this error is occuring while executing the Publishing Wizard, it usually indicates that there is a mismatch on the Select Package screen in the Package Wizard, typically that the value in the Package field does not match the name of the file specified in the Download URL field, or that the file does not exist at all. Also, take note that you cannot directly publish a script as the primary component of a package. The program file of a package definition must be an EXE, MSI, or MSP. So, if you selected EXE, but then defined the Package field as some other filetype, the file validation will also fail.
Now, it is theoretically possible to build a package with, for example, CSCRIPT.EXE as the package file, and then specify a VBS file on the command line and include the VBS (and CSCRIPT.EXE) in the Additional Files listing.
Another way you can approach scripting files in a package, is to wrap the VBS into a self-extracting EXE, and define the EXE as the package installer file. Then in a <postexecution><programs><program> element, you can execute CSCRIPT (from the local instance of CScript.exe) and call the VBS file that was transported in the self-extracting EXE.