1 reply to this topic

[MrSmersh]

I did get myself in one argument over 2 issues on the sidelines of a presentation.

So the first one is the recommendation to check setups for fields or values or so using Orca.
Background: the discussion was about Windows 7 and how to check if a custom action needs elevation or administrative rights and the audience were generic developers not setup developers.
My argument was that Orca is a too powerful tool (considering the audience) to use for checking (modification will break the setup), and the best solution is an ICE rule. Also an ICE rule can be checked and reported at each build and as such is well integrated in the development lifecycle.

The second argument was about the affirmation that Click Once is the best business solution. Yes for sure there are scenarios where Click is the best option but there are a lot on which is not… I would rather say that is a solution but I would rather avoid it in a good part of the business scenarios.

So what is your take I’m right or I’m wrong? What is the best practice on these scenarios?

Thank you!

[Zweitze]

About MsiEval2 / Orca:
I used MsiEval2 in an automated build process, storing its results in the build 'manifest' (a file with description of file names, versions, msi package version, etc.etc. When MsiEval2 finds a problem, it does not break the build though. It was only for validation.

I used Orca to fix the problems that appeared during validation. When you do that in Orca, the problem cells are highlighted in red, making it rather easy to find the source of the problems.