Wow, great findings. It is always good to know, why something strange happened.
Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Gesendet: Mittwoch, 10. Juli 2013 18:39
An: Windows Installer XML toolset developer mailing list
Betreff: Re: [WiX-devs] SFBUG: 3341/3340
Argh! (Delete long running ramblings of the 400 things I tried…)
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372919(v=vs.85).aspx
The certificates are “stored” in the temporary _Streams table, which has a
definition for Name as a max length of 62 characters. When MsiDatabaseImport
is importing the certificates, it uses the notation of TableName.Identifier for
the stream. So, the max length for an identifier on the MsiDigitalCertificate
table is 40, not 72. (Sure would be nice if we had a meaningful error message
for this. I wonder why we don’t set the length of the column to the right
value.)
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Wednesday, July 10, 2013 9:38 AM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] SFBUG: 3341/3340
Re: ::MsiDatabaseImport()
It is a bit of a pain to debug when there are failures however:
1. MsiDatabaseImport is a couple orders of magnitude faster to create the MSI
over using the SQL queries.
2. MsiDatabaseImport creates the smallest MSI files. The SQL insert/update
queries can add "hot air" to an MSI so we want to minimize their use to what is
absolutely necessary.
On Tue, Jul 9, 2013 at 10:57 AM, Hoover, Jacob <jacob.hoo...@greenheck.com>
wrote:
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
<http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk>
&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
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
