OKI've changed the package ID to the question marks and tried changing
the 3rd field in the product versionran the installer again and now I
get...
Another version of this product is already installed. Installation of this
version cannot continue. .
More googling for me today then.
The bit in Derek's article under Here's how it works explains how it works.
It computes the full target path for the single file in the component
(multiple files are not supported). It then generates the GUID as a hash of
the full target path. That means that as long as you don't change the target
So the only way I seem to be able to get this to work is to change the
product guid as well as the package guid.
that doesn't seem right but it seems to work
--
View this message in context:
http://www.nabble.com/Default-regsearch-values-and-upgrading-tf4611878.html#a13189207
Sent from the wix-
The DigitalCertificate element is for:
a) validating signatures on external cabinets (presumably built separately
with makecab);
b) (MSI 3.0 and later) indicating the set of certificates which are allowed
to sign patches that can be installed on a per-machine installation by
non-privileged users
sorted it. http://www.nabble.com/file/p13190669/eProject.wxs eProject.wxs
--
View this message in context:
http://www.nabble.com/Default-regsearch-values-and-upgrading-tf4611878.html#a13190669
Sent from the wix-users mailing list archive at Nabble.com.
On 13 Oct 2007, at 13:56, Mike Dimmick wrote:
> The DigitalCertificate element is for:
>
> a) validating signatures on external cabinets (presumably built
> separately
> with makecab);
>
> b) (MSI 3.0 and later) indicating the set of certificates which are
> allowed
> to sign patches that can
Hey Mike,
Thanks for the reply. Here is what I observed:
1)You are right about compile time Vs link time. The guids are generated
at link time
2)The GUID is pretty much stable (rather same) across all MSI where a
fragment (locale independent) is used. However, I still th
On 13 Oct 2007, at 18:53, Laxmi Narsimha Rao Oruganti (SQL CE) wrote:
> 2)The GUID is pretty much stable (rather same) across all MSI
> where a fragment (locale independent) is used. However, I still
> think that for performance reasons, the GUID getting generated at
> compile time is be
To answer why it's done at bind time, instead of compile time... The hash for
the GUID is generated based on the install path. That path is constructed from
the directory tree which is not complete until all the wixobj's have been
linked together. Furthermore, those paths may contain bind time v
Laxmi Narsimha Rao Oruganti (SQL CE) wrote:
*2)*The GUID is pretty much stable (rather same) across all MSI
where a fragment (locale independent) is used. However, I still think
that for performance reasons, the GUID getting generated at compile
time is better. Don't know with whom I ca
Thanks folks for all your replies. Here are details from me:
1)I have a fragment which I compile once; This fragment has locale
independent components
2)I have WXS which has ref-ed the fragment and has locale dependant
component. This is compiled multiple times (multiplicity is the n
11 matches
Mail list logo
