eigenes Zertifikat

[haentschman]

Moin...:P

Zum Abschluß:
Matthias hat sich gemeldet (Workaround):

Zitat:

Als
Workaround könntest Du das madExceptWizard_.bpl in der IDE entfernen
(oder nur den Haken löschen), und dann stattdessen madExceptPatch.exe
in dem PostBuild-Event manuell ausführen bevor Du die Signierung
machst. Ist natürlich recht unbequem, weil Du dann auch den
Einstellungs-Dialog nicht mehr hast. Alternativ könntest Du das bpl
drin lassen, und stattdessen madExcept für Dein Projekt deaktivieren,
und dann in der madExcept-Configuration madExcept sagen, daß es die
Units nicht aus dem DPR löschen soll, so daß madExcept noch ins Exe
gelinkt wird, und dann wiederum madExceptPatch.exe manuell im
Post-Build-Event aufrufen, mit dem Parameter "/enabled=1", womit dann
die "deaktiviert"-Option in der YourProject.mes Datei auf "aktiv"
überschrieben wird.

Ich habe mich aber für einen Finalbuilder für Arme (finanziell nicht funktional :wink:) entschieden. Da kann ich das in der Reihenfolge machen, wie ich es brauch...:zwinker:

1. Build mit MSBuild
2. Patch MadExcept
3. Signierung

...Fertsch. :thumb:

[himitsu]

Zitat:

und stattdessen madExcept für Dein Projekt deaktivieren,

Sowas in der Art haben wir auch beim Eurekalog schon gemacht.

In allen Projekten haben wir ein Eurekalog-Setting wo nur drin steht Activate=0 (aus) und ExternalConfig="S:\....eof"

Weil wäre schon bissl blöd für jedes der 214 Projekte ein eigenes Setting zu machen, wo es effektiv nur 4 Unterschiedliche gibt.
* BPL, DLL, EXE und Service-EXE (ebenso die RessourceInfo und das WindowsManifest)
* außerdem braucht der ProgrammCode ja auch nur in die EXE rein, während sonst überall die Eurekalog-InfoRessourcen ausreichen

Und DevExpress ist auch überall per Setting aus, weil ist ja bissl schwachsinn, wenn die Styles in jeder DLL drin stecken.



Da die es aber in der IDE genauso machen, wird es wohl die selben Probleme geben. :cry: