Hallo Franz,
wie ich es in der Doku erklärt habe: alle abhängigen DLLs müssen mit einer SNK-Datei signiert sein.
An und für sich müsste das der Hersteller erledigen, es lässt sich aber auch nachträglich machen, müsste nur wieder nachsuchen, wie das geht.
Wolfgang
com_module_sample
Moderator: wriedmann
com_module_sample
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
com_module_sample
Hallo Franz,
dieses Tool sollte das können:
https://brutaldev.com/post/net-assembly ... ame-signer
Ich habe es vor ein paar Jahren anders und aufwendiger gelöst.
Wolfgang
dieses Tool sollte das können:
https://brutaldev.com/post/net-assembly ... ame-signer
Ich habe es vor ein paar Jahren anders und aufwendiger gelöst.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
com_module_sample
Hallo Wolfgang,
ich habe das Tool ausprobiert, von den 3 abhängigen DLLs konnte es 2 signieren, die jose-jwt.dll brachte eine Fehlermeldung und konnte nicht signiert werden. Die beiden signierten DLLs habe ich im Ordner xideprojectstestbindebug ausgetauscht und die X# Testapp, welche meine DLL aufruft, gestartet. Es kommt aber die gleiche Fehlermeldung: für pcsc-sharp.dll wird eine strongly-named assembly benötigt.
Ich habe testweise auch noch ausprobiert, wie sich die beiden signierten DLLs mit meiner originalen C# DLL verhalten. Das hat dazu geführt, dass diese mit den beiden signierten DLLs nichts anfangen konnte und die Zugriffe auf den Smartcard Reader nicht klappten.
Wieso kann die C# com enabled DLL mit unsignierten Fremd DLLs umgehen und die X# com enabled DLL nicht?
ich habe das Tool ausprobiert, von den 3 abhängigen DLLs konnte es 2 signieren, die jose-jwt.dll brachte eine Fehlermeldung und konnte nicht signiert werden. Die beiden signierten DLLs habe ich im Ordner xideprojectstestbindebug ausgetauscht und die X# Testapp, welche meine DLL aufruft, gestartet. Es kommt aber die gleiche Fehlermeldung: für pcsc-sharp.dll wird eine strongly-named assembly benötigt.
Ich habe testweise auch noch ausprobiert, wie sich die beiden signierten DLLs mit meiner originalen C# DLL verhalten. Das hat dazu geführt, dass diese mit den beiden signierten DLLs nichts anfangen konnte und die Zugriffe auf den Smartcard Reader nicht klappten.
Wieso kann die C# com enabled DLL mit unsignierten Fremd DLLs umgehen und die X# com enabled DLL nicht?
com_module_sample
Hallo Franz,
den Unterschied, den es da zwischen C# und X# gibt, kenne ich nicht.
Es ist nur dokumentiert, dass eine COM-DLL signierte DLLs nachladen muss.
Es ist aber durchaus möglich, dass die jose-jwt.dll keine .NET DLL ist und daher nicht mit einem SNK-Schlüssel signiert werden kann. Dann braucht sie es aber auch nicht.
Und ich gehe davon aus, dass nach dem Signieren Deine DLL neu erzeugt werden muss.
Wolfgang
den Unterschied, den es da zwischen C# und X# gibt, kenne ich nicht.
Es ist nur dokumentiert, dass eine COM-DLL signierte DLLs nachladen muss.
Es ist aber durchaus möglich, dass die jose-jwt.dll keine .NET DLL ist und daher nicht mit einem SNK-Schlüssel signiert werden kann. Dann braucht sie es aber auch nicht.
Und ich gehe davon aus, dass nach dem Signieren Deine DLL neu erzeugt werden muss.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
com_module_sample
Hallo Wolfgang,
ich habe die beiden Fremd DLLs, die sich signieren lassen, signiert und bei references angegeben. Die jose-jwt.dll ist unverändert, da sie sich nicht signieren läßt.
Damit startet meine X# Testapp, läuft durch bis zum ersten Aufruf einer der beiden signierten Fremd DLLs.
Das ist ein Aufruf aus der signierten Fremd DLL Gma.QrCodeNet.Encoding.dll. Hier erfolgt der Abbruch mit Meldung
Es sieht also aus, als ob die X# App die signierte Fremd DLL nicht ansprechen kann.
Ausserdem ist mir aufgefallen, dass die signierten Fremd DLLs nicht funktionieren wenn ich meine DLL ohne COM aufrufe, ebenso wenig in der C# Original App. In beiden Fällen werden die unsignierten DLLs benötigt.
ich habe die beiden Fremd DLLs, die sich signieren lassen, signiert und bei references angegeben. Die jose-jwt.dll ist unverändert, da sie sich nicht signieren läßt.
Damit startet meine X# Testapp, läuft durch bis zum ersten Aufruf einer der beiden signierten Fremd DLLs.
Code: Select all
qrCodeImgControl := QrCodeImgControl{}
Code: Select all
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at Program.Start() in C:XIDEProjectsTESTApplicationsRKSVEnabledXPrgProgram.prg:line 53
Ausserdem ist mir aufgefallen, dass die signierten Fremd DLLs nicht funktionieren wenn ich meine DLL ohne COM aufrufe, ebenso wenig in der C# Original App. In beiden Fällen werden die unsignierten DLLs benötigt.
com_module_sample
Hallo Franz,
dann kann es schon sein, dass dieses Tool nicht funktioniert.
Sollte vielleicht mit sn.exe auch direkt funktionieren:
https://docs.microsoft.com/en-us/dotnet ... trong-name
Wolfgang
dann kann es schon sein, dass dieses Tool nicht funktioniert.
Sollte vielleicht mit sn.exe auch direkt funktionieren:
https://docs.microsoft.com/en-us/dotnet ... trong-name
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
com_module_sample
Hallo Wolfgang,
die auf der Seite angegebenen Varianten zur Signierung setzen alle den Sourcecode voraus.
Bin ich der erste und einzige der eine X# com enabled Dll mit Fremd Dlls erzeugen möchte?
Die Fehlermeldung nach der Signierung der Fremd Dlls mit dem StrongNameSigner lautet allerdings etwas anders als zuvor:
Es existiert ein PublicKeyToken, der wurde allerdings autom. erzeugt und stimmt nicht mit dem PublicKey meiner DLL überein.
Daraufhin habe ich die beiden Fremd DLLs mit meinem eigenen PublicKey signiert, es kommt aber die gleiche Meldung nur halt mit meinem PublicKey.
die auf der Seite angegebenen Varianten zur Signierung setzen alle den Sourcecode voraus.
Bin ich der erste und einzige der eine X# com enabled Dll mit Fremd Dlls erzeugen möchte?
Die Fehlermeldung nach der Signierung der Fremd Dlls mit dem StrongNameSigner lautet allerdings etwas anders als zuvor:
Code: Select all
System.IO.FileLoadException: Could not load file or assembly 'pcsc-sharp, Version=3.2.0.0, Culture=neutral, PublicKeyToken=66e06f13f1b53236' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'pcsc-sharp, Version=3.2.0.0, Culture=neutral, PublicKeyToken=66e06f13f1b53236'
at RKSV.Light.APDU.APDUMaster.GetReaders(String[]& readers)
at RKSVComEnabledX.RKSVCom.GetReadersReturned() in
C:XIDEProjectsTESTApplicationsRKSVComEnabledXPrgRKSVComComplete.prg:line 332
Daraufhin habe ich die beiden Fremd DLLs mit meinem eigenen PublicKey signiert, es kommt aber die gleiche Meldung nur halt mit meinem PublicKey.
com_module_sample
Hallo Franz,
nein, Du bist nicht der erste, das ist mir auch passiert.
Eigentlich sollten alle Fremd-DLLs von Haus aus signiert werden - das macht das Devteam mit den X#-DLLs und ich mit meinen auch.
Augenscheinlich ändert der StrongNameSigner auch das Manifest - was nicht passieren dürfte.
Und ein Signieren von Fremd-DLLs ist definitiv möglich, hatte ich auch gemacht (die neueren Versionen der entsprechenden C#-DLL hat der Hersteller dann selber signiert). Laut dem, was ich dem Hersteller damals geschrieben hatte, habe ich die DLLs disassembliert und dann neu assembliert.
Ich habe jetzt nochmals gesucht, und das hier gefunden:
https://stackoverflow.com/questions/137 ... ecifically
Wolfgang
nein, Du bist nicht der erste, das ist mir auch passiert.
Eigentlich sollten alle Fremd-DLLs von Haus aus signiert werden - das macht das Devteam mit den X#-DLLs und ich mit meinen auch.
Augenscheinlich ändert der StrongNameSigner auch das Manifest - was nicht passieren dürfte.
Und ein Signieren von Fremd-DLLs ist definitiv möglich, hatte ich auch gemacht (die neueren Versionen der entsprechenden C#-DLL hat der Hersteller dann selber signiert). Laut dem, was ich dem Hersteller damals geschrieben hatte, habe ich die DLLs disassembliert und dann neu assembliert.
Ich habe jetzt nochmals gesucht, und das hier gefunden:
https://stackoverflow.com/questions/137 ... ecifically
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
com_module_sample
Hallo Wolfgang,
ich habe die beiden Fremd DLLs jetzt laut dem Link disassembliert und wieder assembliert. Die X# Testapp startet nun, steigt aber beim ersten Aufruf dieser DLLs mit dem gleichen Fehler aus, wie bei den unsignierten DLLs (siehe #22491).
Der StrongNameSigner zeigt auch an, dass die beiden DLLs signiert sind. Sie funktionieren allerdings nicht mehr, wenn ich meine DLL ohne COM aufrufe, ebenso wenig in der C# Original App.
ich habe die beiden Fremd DLLs jetzt laut dem Link disassembliert und wieder assembliert. Die X# Testapp startet nun, steigt aber beim ersten Aufruf dieser DLLs mit dem gleichen Fehler aus, wie bei den unsignierten DLLs (siehe #22491).
Der StrongNameSigner zeigt auch an, dass die beiden DLLs signiert sind. Sie funktionieren allerdings nicht mehr, wenn ich meine DLL ohne COM aufrufe, ebenso wenig in der C# Original App.
com_module_sample
Hallo Franz,
das muss ich mir anschauen.... der Hersteller der DLLs ist nicht greifbar?
Könntest Du die DLLs mal hier hinhängen (wenn die nicht urheberrechtlich geschützt sind).
Wolfgang
das muss ich mir anschauen.... der Hersteller der DLLs ist nicht greifbar?
Könntest Du die DLLs mal hier hinhängen (wenn die nicht urheberrechtlich geschützt sind).
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it