No, I am still using MsiDatabaseImport too, as I just wanted a quick fix. I
did it the same way as you described (reading the certificates from the
table if it exists, calculating the thumbprint and reusing its identifier).
I think including a certificate twice with different identifiers doesn't
make sense, so I remove those silently.
Changing away from MsiDatabaseImport is probably better. I noted that by
using MsiDatabaseImport no validation entries are added to the MSI database,
if the tables do not exist before. I don't know if those entries are needed,
but I'm getting an ICE error when they are missing. I've included some
<EnsureTable> elements in my installer, to force the creation of the tables
before using Insignia.
Kind regards,
Georg von Kries
Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Gesendet: Mittwoch, 10. Juli 2013 02:53
An: Windows Installer XML toolset developer mailing list
Betreff: Re: [WiX-devs] SFBUG: 3341/3340
In your solution, did you transition away from using MsiDatabaseImport? I
was going to change to using DTF after reading the comments on the docs
(http://msdn.microsoft.com/en-us/library/windows/desktop/aa370079(v=vs.85).a
spx) where it says export/import is "not intended to be used as a means of
editing data". However, it looks like all the tables the binder is creating
is using this same function. The binder has the luxury of knowing that the
tables won't exist, while insignia may or may not be dealing with a MSI
which has the table.
I've blurred these two fixes together locally, where I am now extracting the
existing certificates and calculating the Thumbprint of them. With that, I
am pre-populating the certificates dictionary with the Thumbprint and the
existing identifier. This allows insignia to use the same identifier as the
one that existed in the db.
I'm looking for comments on if that would be considered overkill, and if
there is ever a use case where you would want the same certificate in the
table with different identifiers.
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: Tuesday, July 09, 2013 2:22 PM
To: 'Windows Installer XML toolset developer mailing list'
Subject: Re: [WiX-devs] SFBUG: 3341/3340
I had the same behavior and it was working when using a shorter identifier.
But your right, the reason must be something else.
Von: Hoover, Jacob [mailto:Jacob.Hoove <mailto:jacob.hoo...@greenheck.com>
r...@greenheck.com]
Gesendet: Dienstag, 9. Juli 2013 21:00
An: Windows Installer XML toolset developer mailing list
Betreff: Re: [WiX-devs] SFBUG: 3341/3340
No, I've verified my identifier was only 41 characters long. Looking at the
idt, the field is defined as s72, or a 72 character string (confirmed with
Orca). Even with Orca, I was unable to change the identifier to "X", so it
isn't a length issue.
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: Tuesday, July 09, 2013 1:27 PM
To: 'Windows Installer XML toolset developer mailing list'
Subject: Re: [WiX-devs] SFBUG: 3341/3340
Hi,
my messages are too long, they need moderation. I've fixed these too bugs
and wanted to post my changes.
Actually I think the identifier is getting too long in your case. I've used
an Guid prefixed by 'cer' as an identifier instead of the thumbprint.
Kind regards,
Georg von Kries
Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Gesendet: Dienstag, 9. Juli 2013 19:58
An: Windows Installer XML toolset developer mailing list
Betreff: [WiX-devs] SFBUG: 3341/3340
When looking at SFBUG 3340 and 3341, I attempted to prefix the identifier.
Any time I use anything other than the hash it fails to import. I've tried
multiple variations (_, cer, Z, etc) of a prefix. Each time I have verified
that the certificate name in the IDT matches that of the file on disk in the
MsiDigitalCertificate sub folder. I've tried it with only changing the
identifier and with changing both the identifier and the file name.
By chance is there something mis-documented on either the table definition
or the MsiDatabaseImport function? (Is there a reason we are using this
instead of using the DB functions directly?)
It may be worth mentioning that I can't even adjust this value with Orca. It
fails on commit with "The data was rejected by the database. It may be out
of the valid range or formatted incorrectly". I can modify the identifier
in the MsiDigitalSignature table, and I can modify another record in the
MsiDigitalCertificate table. (I have a local fix that leaves the named key
from the MsiPatchCertificate table in place.) The only other unique thing I
can think of is both certs are identical.
Thanks,
Jacob
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
