Do you use ConflictSolver ... why?

[looeee]

Hi
I've been using AdminStudio since its first release, and I've always wondered what ConflictSolver is for.

It doesn't find many conflicts in my packages when they clearly are there and it incorrecly finds ones that are not there.

I am wondering if there is anyone out there who finds it useful and if so what do you use it for?

[Christopher_Pai]

I never did. Maybe I was really missing the big picture but I never put the application catalog or conflict solver to work. ( Unless you count myself as the conflict solver. )

[Inabus]

You should be using the conflict solver. Basically we use it to find multiple conflicts between packages. The usual 1 we see is 2 different packages deploying the same file however the files are different versions. We have both our terminal server and desktop environment builds inside the system and add the packages in and resolve them agaisnt the builds etc.

Very useful tool to ensure no issues arise with your packages!

Paul

[looeee]

Hi Paul

I understand what you are doing and I've been 'using' it for years myself, but I don't believe that it does anything near what is claimed.

If you run MSIDiff on your two packages and compare the component tables I am certain that you will be loudly sweary when you see the components that should be synchronised and are not.

Every corporation that I have been involved with that needs to do any conflictsolving uses the Macrovision effort solely for the purpose of importing into SQL server (something it is reasonably good at) and then use all their own custom queries to do any kind of work to identify and resolve conflicts.

[Christopher_Pai]

Inabus wrote:
You should be using the conflict solver. Basically we use it to find multiple conflicts between packages. The usual 1 we see is 2 different packages deploying the same file however the files are different versions. We have both our terminal server and desktop environment builds inside the system and add the packages in and resolve them agaisnt the builds etc.

Very useful tool to ensure no issues arise with your packages!

Paul

To me this solves a problem that was already solved by another WindowsInstaller technology: Merge Modules

If you isolate your applications and componentize your shared files into merge modules I don't see why you would need conflict solver.

[looeee]

Christopher Painter wrote:
If you isolate your applications and componentize your shared files into merge modules I don't see why you would need conflict solver.

uuh because ISVs don't have access to your MSM library

[Christopher_Pai]

We aren't talking about ISVs, we are talking about IT shops. If an ISV is redistributing my files they better have a license agreement and my merge modules or they will be seeing my lawyers.

IT shops gather MSM's from MS,IS and other ISV's and build their library. The repackager will replace components with MSMs when approriate.

When I did repackaging, anytime that the repackager created a component that went to a shared location such as SYSTEM32 I either isolated the application or created a merge module for the files.

Then when future installs were created we consumed the merge modules instead of reauthoring the component and use a tool like conflict solver to magically sync the components.