Software Deployment

If you install this application on a machine that also has Office 2003 installed, that file is going to end up at the Office version level. Do you care? Maybe.

To answer your question...

1) Yes. Include the highter version and test it. It will usually work fine, but if it doesn't then you'll know that Office 2003 will break this app by upgrading MSCOMCTL.OCX. That .ocx file MUST be isolated in order for this app to work with Office 2003 on the same machine.

2) No. Add it in a transform (.mst) and leave the original vendor MSI file intact.

3) No. Definitely do not ignore it. Even though this won't produce a problem 95% of the time, the remaining 5% could cause a big problem because the problems will only surface after you've deployed the app to many machines (and replicated the problem). Always better safe than sorry.

Thanks for quick reply .

Quick question :

If i add higher version file to MSCOMCTL.MSM and assume my application works fine , then will I have to make change to all of my applications I have packaged till now ?

Thanks in advance .

Cheers ,
V

That would entail changing all packages & redistribute / repair all packages on all machines. That would also need to be done every time an app gets packaged with an updated dll/ocx. It's ideal, but this is a crazy amount of work. Not worth it.

Since you know all applications that will have files upgraded when you do conflict checking, just add those applications to your QA testing for the new app. If the existing packages work with the newer versions installed by the new app (and they usually do) then all will be well if the new app upgrades the files. If the existing packages fail testing, then you'll know if the new app will break an existing package before you deploy it. Then you'll have time to decide the best way to resolve the conflict, which is best determined on a case by case basis.

Just to make sure your merge module is good you should self register the OCX and make sure there are no new COM entries that the MSM does not have. Chances are nothing changed but you don't want to find out after the fact.

For Clarification :
Are you suggesting that If the application works when new application is installed then ignore the conflict and move ahead , but if any of the applications fail the test then take them and do conflict resolution case by case .

ORIGINAL: VikingLoki

That would entail changing all packages & redistribute / repair all packages on all machines. That would also need to be done every time an app gets packaged with an updated dll/ocx. It's ideal, but this is a crazy amount of work. Not worth it.

Since you know all applications that will have files upgraded when you do conflict checking, just add those applications to your QA testing for the new app. If the existing packages work with the newer versions installed by the new app (and they usually do) then all will be well if the new app upgrades the files. If the existing packages fail testing, then you'll know if the new app will break an existing package before you deploy it. Then you'll have time to decide the best way to resolve the conflict, which is best determined on a case by case basis.

Not quite. You're not ignoring the conflict, you just have to address it differently depending on if the existing deployed version is older or newer.

If your new package has a conflict with an existing deployed package, and the deployed package has the newer dll version, then you upgrade the new package to the dll you have out there and test it. Easy.

If the deployed package has the older dll version, it's not so easy. You can't just update it because the dll is distributed everywhere already and you're not going to redistribute it every time a new dll comes in the door. In that case, a "real world" test is more in order. Install your existing package, then install the new package. That will update the old dll to the new. Then you test the old application to insure the newer dll will function with it.

Both ways the new dll ends up on the target machine, and both ways you test before it happens.

Remember, conflicts don't necessarily need to be eliminated. It's only necessary to find them and test them, so you know it will be ok before it reaches the users. (Note how Wise calls it Conflict Management, not Conflict Resolution)

Rarely, you'll find a situtation where an app works with the old dll but not with the new. When that happens, you have to use best judgement to resolve it. Maybe an even newer version works? Maybe you should isolate the older package and redeploy? Maybe keeping the old dll works with the old and the new. All are valid, the best one depends on the situation.

Hi VikingLoki ,

Thanks a bunch for this elaborate explanation .

My concepts are much clearer now [:)]

Cheers ,
V