I don’t have anything else to add. I was creating a certificate instance in
memory and checking its thumbprint before writing it to disk, but this was the
only difference.
Kind regards,
Georg
Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Gesendet: Mittwoch, 10. Juli 2013 20:32
An: Windows Installer XML toolset developer mailing list
Betreff: Re: [WiX-devs] SFBUG: 3341/3340
Common.GenerateIDentifier is what I had initially done but then I remembered
that the “stable guids” promised on components used this method. Will see what
Rob says on my other questions and I’ll do another commit/pull request. (Feel
free to comment on any things I might have missed but you covered, I’d
appreciate more reviews and suggestions.)
Thanks,
Jacob
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: Wednesday, July 10, 2013 12:49 PM
To: 'Windows Installer XML toolset developer mailing list'
Subject: Re: [WiX-devs] SFBUG: 3341/3340
Thanks, almost the same way I did it. I was just thinking about using
Common.GenerateIdentifier("cer", false, cert2.Thumbprint) instead of Guids to
be consistent.
Kind regards,
Georg von Kries
Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Gesendet: Mittwoch, 10. Juli 2013 19:41
An: Windows Installer XML toolset developer mailing list
Betreff: Re: [WiX-devs] SFBUG: 3341/3340
http://wix.codeplex.com/SourceControl/network/forks/jchoover/Wix?branch=SFBUG3340
Pushed my proposed changes for 3.8. Should I submit a pull request or can I
get some feedback first?
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: Wednesday, July 10, 2013 11:59 AM
To: 'Windows Installer XML toolset developer mailing list'
Subject: Re: [WiX-devs] SFBUG: 3341/3340
Thanks Rob. The changes were so small that I thought I just send them this way.
Looks like Jacob is doing a better job than me anyways.
My Guids are currently not stable. Why do they have to be stable there? Those
identifiers are added automatically and are only referenced by insignia itself
and inside a single MSI database.
Regards,
Georg
Von: Rob Mensching [mailto:r...@robmensching.com]
Gesendet: Mittwoch, 10. Juli 2013 16:40
An: Windows Installer XML toolset developer mailing list
Betreff: Re: [WiX-devs] SFBUG: 3341/3340
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 <g...@creativbox.net> 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: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
<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
