I’ve been working on getting rid of ICE errors and warning and I’ve come across a few that I’m having trouble fixing.
ICE33 – xxx is used in an unsupported way. ProgId should be registered via the ProgId table. This entry may overwrite a value created through that table
In reading thru the archives it appears not to be a good idea to use the Class/ProgId/TypeLib/Interface elements?
<snipped from the archive>
Essentially, using the Class and ProgId tables (several others as well) sets
those Resources up to be "advertised". This has the advantage of getting
you "resiliency" (aka: auto-repair) if the COM server gets out of whack.
Unfortunately, that same feature means the Windows Installer is validating
the state of your COM server every time it is invoked. Now, the performance
hit here is negligible. The problem is that it is very easy to end up in
states where the COM server is perpetually in a "broken" state.
Have you ever had the Windows Installer just start popping up randomly for
some other application while you"re using another? 99% of the time that"s
because somewhere advertised COM registration has become a little wonky.
Over the years, teams at Microsoft have learned that any benefits provided
from advertising COM registration are far out numbered by the seemingly
random bugs caused by it. MS PSS hates it.
And, yes, I"m sure you can argue that you are smarter than everyone else and
you can get the registration right and because you never share code with
anyone else and only your own application uses it"s own CLSIDs and because
you"ve never seen the problem that you can get this right and should still
use the Class and ProgId table.
But I wouldn"t suggest it... <smile/>
<snipped end>
I don’t own the registration info and in the past the owners changed the values without informing us and then tallow is used to extract the values. From a maintenance standpoint I much rather use the registry entries than use Class/ProgId/TypeLib but I also want to follow best practices.
ICE43 – xxx has non-advertised shortcuts. It should use a registry key under HKCU as its KeyPath, not a file
ICE57 – xxx has both per-user and per-machine data with a per-machine KeyPath.
All of the packages have ALLUSERS = 1 and the shortcuts are not published what is the best way to correct these errors?
Thanks
Danny Smith
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
