Sounds great. We need to get you an assignment agreement, please see:
http://wixtoolset.org/about/assignment-agreement/

Also, to have us start reviewing the changes send a pull request. Don't try
to attach patches here.

Note: The identifier needs to be stable so if you used a Guid it will need
to be the same Guid for that particular thumbprint for every build.




On Tue, Jul 9, 2013 at 11:26 AM, Georg von Kries <[email protected]> wrote:

> 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:[email protected]]
> *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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs

Reply via email to