Bob Arnson írta:
> Szentpali Janos wrote:
>> Can you suggest some strategy to help one install components that do not
>> come in msi-s or msm-s but that are shared/common components that
>> could/would possibly be installed by non msi setups
>
> If you're not using stable component IDs through MSI,
Szentpali Janos wrote:
> Can you suggest some strategy to help one install components that do not
> come in msi-s or msm-s but that are shared/common components that
> could/would possibly be installed by non msi setups
If you're not using stable component IDs through MSI, the closest you'll
get
Bob Arnson írta:
> Szentpali Janos wrote:
>> Does that mean that the same file, installed by two unrelated setup
>> packages into the same path, with two distinct component and file ids
>> (guids) will still be correctly uninstalled/managed?
>
> No, that's what component rules are about. The compo
Szentpali Janos wrote:
> Does that mean that the same file, installed by two unrelated setup
> packages into the same path, with two distinct component and file ids
> (guids) will still be correctly uninstalled/managed?
No, that's what component rules are about. The component GUID and
resource I
Bob Arnson írta:
> Szentpali Janos wrote:
>> "Merge modules are generally now considered bad practice..." If this
>> is true than what is the point of the whole MSI system? I mean if I
>> have a 3rd party component (x.dll) that 4th party and 5th party are
>> using too, how does the system decide th
Szentpali Janos wrote:
> "Merge modules are generally now considered bad practice..."
> If this is true than what is the point of the whole MSI system? I mean if I
> have a 3rd party component (x.dll) that 4th party and 5th party are using
> too, how does the system decide that the x.dll compone
Ugh, I just send this reply but forgort to include the Subject:
Anyway,
Thanks. I did get everything working with the merge module, and I did find the
standalone MSI alternative to the merge module. I hope that the licensing is
the same with the XTal MSI as with the merge module.
I do use Orca
"Merge modules are generally now considered bad practice..."
If this is true than what is the point of the whole MSI system? I mean if I
have a 3rd party component (x.dll) that 4th party and 5th party are using too,
how does the system decide that the x.dll component installed by the 4th
party'
Merge modules are generally now considered bad practice - they become
impossible to service, because the module does not retain its identity. The
only way to service them is to patch the products which have merged the
module. Crystal Reports had a security patch earlier this year:
http://www.micros
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Crystal Reports modules not registering files
Hello Richard, thank you for your help.
I will try to include the SelfRegModules action and test it on a
virtual machine, and see if that solves the problem.
Do you know where can I get the Crystal Reports r
Hello again.
I had the opportunity to test this on a virtual machine, and including
the SelfRegModules action solved the problem. Now it seems that
everything is being registered.
About the 2008 runtime msi. It doesn't work for me because we're using
the activex viewer from crystal XI and its not
Hello Richard, thank you for your help.
I will try to include the SelfRegModules action and test it on a
virtual machine, and see if that solves the problem.
Do you know where can I get the Crystal Reports runtime MSI packages?
We are using version XI, and in the crystal page, I can only find
MS
Pedro,
My first recommendation would be to use a bootstrapper and the Crystal
reports runtime MSI file instead of the merge modules. The merge modules
are IMHO almost useless, not to mention the fact that if you use WiX 3
you'll have to turn off verification because the CR merge modules have
so ma
Certainly can.
Here's the
http://support.businessobjects.com/communityCS/FilesAndUpdates/cr10_rdc_merge_modules.zip
Crystal merge modules I'm trying to include.
I've attached a http://www.nabble.com/file/3855/CR10.wxs test file which
produces the error.
I was using Visual Studio 2005 which
LGHT0001 indicates an UnexpectedException, which basically means any error
that the WiX developers haven't explicitly handled. Is there any stack trace
at all? Can you provide a repro case?
--
Mike Dimmick
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
15 matches
Mail list logo
