Hi ,

I am repackaging an application which is showing conflicts with MSCOMCTL.OCX version used in Microsoft Office 2003 .

The version of the file used in the MSCOMCTL.MSM is 6.0.88.62 while the the version used in Office 2003 is 6.1.95.45 .

My question is :

1) Shall I include the higher version file in MSCOMCTL.MSM ?
2) Shall I make change directly to the Application MSI and replace lower version file with the higher version ?
3) Shall I ignore this conflict ?

Are there any best practices followed in such cases ?

Cheers ,
V
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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.
Answered 06/13/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
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
Answered 06/13/2005 by: viv_bhatt1
Senior Purple Belt

Please log in to comment
0
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.
Answered 06/13/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
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.
Answered 06/13/2005 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
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.
Answered 06/14/2005 by: viv_bhatt1
Senior Purple Belt

Please log in to comment
0
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.
Answered 06/14/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
Hi VikingLoki ,

Thanks a bunch for this elaborate explanation .

My concepts are much clearer now [:)]

Cheers ,
V
Answered 06/15/2005 by: viv_bhatt1
Senior Purple Belt

Please log in to comment
Answer this question or Comment on this question for clarity