Software Deployment

In addition to advertised shortcuts, file associations are also entry points for applications and can trigger self heals. If you create your HKCU entry under the same feature that the pdx file association is created under (as an example) you'll notice that when you try to open a *.pdx file (create a bogus one whatever.pdx) it will self heal and create your entry.

So, you could try to create a .pdf file association so that whenver a .pdf is ran, it will trigger the self heal and you're good to go.

Best of luck!

If you want a self-check to occur when a PDF is opened in a ex. Internet Explorer you would need to make sure the Registration information for AcroIEHelper.dll, AcroPDF.dll or pdfshell.dll (don't know which one but all three is used as ActiveX components) is advertised and not through the Registry table as they currently are.

If the advertised file association is correctly "setup" then a self-check should also occur when any associated file-type is triggered.

you would need to make sure the Registration information <snip> is advertised and not through the Registry table as they currently are.I've read here that the MSI was bad but is this for real, Kim?!? I think Adobe is determined to hit the No. 1 spot for Worst MSI.

I just took a quick look and that is what I saw, I could be wrong.....NAAAA [;)]
Adobe has always been a good candidate for this spot, haven't they!

Hi AngelD,

That's what I couldn't figure out and I hope you can give me some direction.

One of the feature is "ReaderBrowserIntergration" and 4 components.
ActiveX_AcroIEHelper.dll
ActiveX_AcroIEHelperShim.dll
ActiveX_AcroPDF.dll
Browser.

I go through all the options but couldn't find a place to ensure they are advertise in InstallSheild2009.
Do you know where in InstallShield I enable this? The feature is currently set to Allow Advertise. Am I looking at the right place?






Allow Advertise

Enables advertisement on this feature. Although advertisement is allowed, it is not the default option when the installation is run.


Favor Advertise

The feature is advertised by default. End users can change the advertisement option for a feature in Custom Setup dialog.


Disallow Advertise

Advertising is not allowed for this feature. End users cannot elect to have the feature advertised in the Custom Setup dialog.


Disable Advertise if Not Supported

Advertisement works only on systems with Internet Explorer 4.01 or later. If the target system does not meet this criterion, advertising is not allowed. If the target system can support advertisement, advertising is allowed.

Do you know where in InstallShield I enable this? There's nothing in IS (or WPS, come to that) that makes it easy to accomplish this. That's what makes the difference between being a packager, as opposed to someone who knows how to drive IS or WPS.

You need to determine which registry entries are associated with the DLLs in question and move them from the Registry table to the relevant advertising tables e.g. Class, Extension, etc. This won't be an easy exercise. You could start by using the IS tools to extract the COM information from those DLLs into .REG files. Then, use the contents of those files to determine what you can delete from the Registry table. Once you've done that, select to import the .REGs and, when prompted (if prompted - I can't recall if IS's default is to use the proper tables...) elect to use the advertising tables rather than the Registry table.

Once you've done that, prepare your proposal to send to Adobe with your price for selling them a proper MSI.

Have you ever actually done that VB?

Always thought about it but never done it hehe.

P

Have you ever actually done that VB?What, approached vendors with my MSIs? I have, yes. I had some discussions with some marketing dweeb at IBM a few years ago but he left and it died. I've also had lots of emails casting aspertions about my abilities over the combined force of [insert vendor name here]'s development teams. See, the thing is, vendors are never wrong. Their installs are perfect, their design decisions beyond reproach. As you know already, of course.

Paul if you track down PGiesenberg (sorry if I spelt it wrong) he has written code to deal with this.

Last I checked it seemed to work ok, but I never did any thorough testing with it. He seems like a pretty smart felllow.

Sorry, yeh was talking about contacting a vendor and saying, your msi is naff use mine :)

P

As repackagers we get a limited view of what issues the Software Development cycle offers.

I have been on both sides of the fence now and I can assure you the issues we face repackaging are a somewhat limited view of the SDLC world.

Even if your MSI is better they would still need to find a way to automate the creation of such an MSI using something like WiX. Daily builds and version control add an interesting layer of complexity over the whole situation.

I recently starting contacting vendors about their somewhat sloppy approach to MSI's. Some is received well some completely ignored from version to version.