Welcome, Guest
Username: Password: Remember me
Hier wird Deutsch gesprochen

TOPIC:

com_module_sample 24 Apr 2022 09:27 #22289

  • wriedmann
  • wriedmann's Avatar


  • Posts: 3094
  • Hallo Franz,
    1) Du musst die ComTestFR.dll ins Verzeichnis kopieren, wo die Exe erstellt wird.
    2) die Klasse IComTester habe ich einfach vergessen zu entfernen, dasselbe gilt fürs Manifest.
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    Last edit: by wriedmann.

    com_module_sample 24 Apr 2022 09:39 #22291

    • lagraf
    • lagraf's Avatar
    • Topic Author


  • Posts: 294
  • Das habe ich auch gemacht, alles 1:1 hinein entpackt, sogar den gleichen Ordner c:\temp\comtest verwendet, damit ich nichts verändern muß! Trotzdem startet die App nicht.
    Attachments:

    Please Log in or Create an account to join the conversation.

    com_module_sample 24 Apr 2022 10:05 #22292

    • wriedmann
    • wriedmann's Avatar


  • Posts: 3094
  • Hallo Franz,
    sorry, da gehört aus dem Manifest der Exe der Verweis auf die ComTestF.DLL raus:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity
        version="1.0.0.0"
        processorArchitecture="X86"
        name="VO.Application"
        type="win32"
    />
    <description>Visual Objects Application.</description>
    <dependency>
        <dependentAssembly>
            <assemblyIdentity
                type="win32"
                name="Microsoft.Windows.Common-Controls"
                version="6.0.0.0"
                processorArchitecture="X86"
                publicKeyToken="6595b64144ccf1df"
                language="*"
            />
        </dependentAssembly>
    </dependency>
    	<dependency>
      	<dependentAssembly>
      		<assemblyIdentity
      			type="win32"
      			name="COMTestFR"
      			version="1.0.0.0"
      			publicKeyToken="0359fa75d6c66754"
      			>
      		</assemblyIdentity>
      	</dependentAssembly>
      </dependency>
    </assembly>
    Mit Nachschauen im EventViewer hättest Du das auch alleine rausfinden können, oder mit der angeführten sxslog.cmd:
    sxstrace Trace -logfile:systrace.out
    sxstrace Parse -logfile:systrace.out -outfile:sxstrace.txt
    notepad sxstrace.txt
    Die ist bei Problemen mit SideBySide immer der erste Schritt.
    Nach dem Ändern des Manifests (ComTestFApp.man) und folgendem kompletten Recompilieren der Applikation ( Application - Rebuild all ) funktioniert es auch in einem separaten Verzeichnis:

    in dem nur Exe und Dll sind.
    Das ist ja das eigentliche Coole an SideBySide, dass es keine Pfadabhängigkeiten gibt, sondern alles aus dem Applikations-Verzeichins geladen wird.
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it
    Attachments:

    Please Log in or Create an account to join the conversation.

    com_module_sample 24 Apr 2022 11:34 #22294

    • lagraf
    • lagraf's Avatar
    • Topic Author


  • Posts: 294
  • Hallo Wolfgang,
    - den Block für ComTestF habe ich aus dem Manifest entfernt
    - den Block für IComTester habe ich aus der VO App entfernt
    - hab auch die X# DLL neu generiert

    Neu generieren der VO App hat nichts geholfen, erst beim Rebuild All ist die App dann gestartet!
    Finden die Änderungen auch Einzug in das Beispiel bei der XSharp Doku?
    Jedenfalls Danke für deine Hilfe!

    Frage: Wenn ich nun weitere Methoden der COM Dll hinzufüge, genügt dann ein compilieren der Dll oder muß woanders auch noch was geändert werden?

    PS: sxstrace kannte ich bisher noch gar nicht, hab ich ausprobiert, bringt aber einen "Unbekannten Fehler" beim Befehl "sxstrace Trace -logfile:systrace.out". Welche sxslog.cmd, hab ich da was überlesen?

    Please Log in or Create an account to join the conversation.

    Last edit: by lagraf.

    com_module_sample 24 Apr 2022 11:47 #22295

    • wriedmann
    • wriedmann's Avatar


  • Posts: 3094
  • Hallo Franz.,
    wenn Du nur die Applikation neu generierst, kompiliert VO die Ressourcen nicht neu, daher steht in der Applikation auch noch das alte Manifest drin.
    Das ist mir nicht aufgefallen, weil ich die ComTestF.dll auch noch in meinem Verzeichnis drin hatte.
    Die Doku werde ich auf jeden Fall anpassen.
    Leider ist Windows bei SxS sehr heikel, aber wenn das mal läuft, dann läuft das sehr stabil. Mittlerweile hat fast jede meiner VO-Applikationen mindestens eine X# COM-DLL dabei, weil es gar nicht mehr anders geht.
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    com_module_sample 16 May 2022 12:02 #22474

    • lagraf
    • lagraf's Avatar
    • Topic Author


  • Posts: 294
  • Hallo Wolfgang,
    ich habe meine X# DLL inzwischen fertig und auch mit einer von VO auf X# umgestellten Kassenapp ausgetestet. Wenn ich jetzt eine com enabled DLL daraus mache, um auch mit VO drauf zugreifen zu können, kann ich dann mit X# auch noch direkt (ohne Umweg über COM) auf die Methoden zugreifen oder brauche ich für X# und VO jeweils eine eigene DLL?

    Please Log in or Create an account to join the conversation.

    com_module_sample 16 May 2022 12:06 #22475

    • wriedmann
    • wriedmann's Avatar


  • Posts: 3094
  • Hallo Franz,
    klar kannst Du dafür eine einzige DLL verwenden - mache ich selber auch mehrfach, und gerade in einer Umstellungsfase auf X# wird das sogar sehr wichtig.
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    com_module_sample 16 May 2022 15:16 #22479

    • lagraf
    • lagraf's Avatar
    • Topic Author


  • Posts: 294
  • Hallo Wolfgang,
    meine DLL ist etwas komplexer als das com_module_sample. Ich habe eine Hauptklasse mit 11 public Methoden, die von VO angesprochen werden sollen. Ausserdem mehrere andere Klassen mit 69 Methoden, die von der Hauptklasse verwendet werden, aber nicht von VO direkt. Der Programmteil ist wie folgt aufgebaut:
    USING System.Runtime.InteropServices
    ...
    BEGIN NAMESPACE RKSVComComplete
    
    [ComVisible(TRUE)];
    [Guid("***Guid1***")];
    [ClassInterface(ClassInterfaceType.None)];
    [ProgId("RKSVComComplete.RKSVCom")];
    PUBLIC CLASS RKSVCom IMPLEMENTS IRKSVCom
       PUBLIC METHOD GetReadersCount() AS LONG
       PUBLIC METHOD GetCardReaders() AS STRING[]
    ...
    END CLASS
    
    PUBLIC CLASS xyz
       PUBLIC METHOD abc
       PUBLIC METHOD def
    ...
    END CLASS
    ...
    END NAMESPACE
    Der Interfaceteil:
    USING System.Runtime.InteropServices
    
    BEGIN NAMESPACE RKSVComComplete
    
    [ComVisible(TRUE)];
    [Guid(""***Guid2***)];
    [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)];
    INTERFACE IRKSVCom
       [DispId(1)];
       PUBLIC METHOD GetReadersCount() AS LONG
    
       [DispId(2)];
       PUBLIC METHOD GetCardReaders() AS STRING[]
    
       ...
    END INTERFACE
    END NAMESPACE
    Für die internen Klassen und Methoden habe ich keine Einträge im Interface angelegt.
    Bis vor den Punkt Manifest erstellen funktioniert alles.
    Beim Erstellen des Manifestes bekomme ich jede Menge Warnings für alle internen Klassen, die nicht von VO direkt genutzt werden:
    G81010014: Explicit guid not defined

    Im Manifest scheinen auch alle internen Klassen auf mit unbekannten Guids. Müssen diese Einträge entfernt werden? Habe ich etwas falsch definiert?

    Please Log in or Create an account to join the conversation.

    Last edit: by lagraf.

    com_module_sample 16 May 2022 15:57 #22480

    • robert
    • robert's Avatar


  • Posts: 2974
  • Franz,

    If you add

    [ComVisible(FALSE)];

    to the classes that you do not want to be included in the COM DLL then it should work.
    Also make sure that you do not have public properties or methods in the classes that you are making visible through that use these types as parameter or return value.

    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    com_module_sample 16 May 2022 17:45 #22481

    • lagraf
    • lagraf's Avatar
    • Topic Author


  • Posts: 294
  • Hi Robert,
    as you said
    • I prefixed all non visible classes with [ComVisible(FALSE)];
    • I deleted PUBLIC at all visible methods
    For testing purposes I have a small X# app which calls these methods directly without COM to see if my DLL works. Using my DLL without COM stuff it does well, but since I added COM stuff I get exceptions with following message for 3 extern libs (Gma.QrCodeNet.Encoiding.dll, jose-jwt.dll and pcsc.sharp.dll) which I use in my DLL:
    System.IO.FileLoadException: Could not load file or assembly 'pcsc-sharp, Version=3.2.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044) File name: 'pcsc-sharp, Version=3.2.0.0, Culture=neutral, PublicKeyToken=null' at RKSV.Light.APDU.APDUMaster.GetReaders(String[]& readers)
    at RKSVComCompleteX.RKSVCom.GetReadersReturned() in
    C:\XIDE\Projects\TEST\Applications\RKSVComCompleteX\Prg\RKSVComComplete.prg:line 332
    What I have to do enabling COM when I use foreign DLLs in my DLL?

    Please Log in or Create an account to join the conversation.

    com_module_sample 16 May 2022 17:53 #22482

    • wriedmann
    • wriedmann's Avatar


  • Posts: 3094
  • 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
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    com_module_sample 16 May 2022 17:55 #22483

    • wriedmann
    • wriedmann's Avatar


  • Posts: 3094
  • Hallo Franz,
    dieses Tool sollte das können:
    brutaldev.com/post/net-assembly-strong-name-signer
    Ich habe es vor ein paar Jahren anders und aufwendiger gelöst.
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    com_module_sample 17 May 2022 07:57 #22488

    • lagraf
    • lagraf's Avatar
    • Topic Author


  • Posts: 294
  • 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 xide\projects\test\bin\debug 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?

    Please Log in or Create an account to join the conversation.

    com_module_sample 17 May 2022 08:07 #22489

    • wriedmann
    • wriedmann's Avatar


  • Posts: 3094
  • 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
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    com_module_sample 17 May 2022 09:34 #22491

    • lagraf
    • lagraf's Avatar
    • Topic Author


  • Posts: 294
  • 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.
    qrCodeImgControl := QrCodeImgControl{}
    Das ist ein Aufruf aus der signierten Fremd DLL Gma.QrCodeNet.Encoding.dll. Hier erfolgt der Abbruch mit Meldung
    Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
    at Program.Start() in C:\XIDE\Projects\TEST\Applications\RKSVEnabledX\Prg\Program.prg:line 53
    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.

    Please Log in or Create an account to join the conversation.

    com_module_sample 17 May 2022 09:58 #22492

    • wriedmann
    • wriedmann's Avatar


  • Posts: 3094
  • Hallo Franz,
    dann kann es schon sein, dass dieses Tool nicht funktioniert.
    Sollte vielleicht mit sn.exe auch direkt funktionieren:
    docs.microsoft.com/en-us/dotnet/standard...bly/sign-strong-name
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    com_module_sample 17 May 2022 10:42 #22494

    • lagraf
    • lagraf's Avatar
    • Topic Author


  • Posts: 294
  • 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:
    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:\XIDE\Projects\TEST\Applications\RKSVComEnabledX\Prg\RKSVComComplete.prg:line 332
    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.

    Please Log in or Create an account to join the conversation.

    Last edit: by lagraf.

    com_module_sample 17 May 2022 11:17 #22496

    • wriedmann
    • wriedmann's Avatar


  • Posts: 3094
  • 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:
    stackoverflow.com/questions/1379954/how-...o-a-dll-specifically
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    com_module_sample 17 May 2022 12:43 #22498

    • lagraf
    • lagraf's Avatar
    • Topic Author


  • Posts: 294
  • 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.

    Please Log in or Create an account to join the conversation.

    com_module_sample 17 May 2022 14:34 #22503

    • wriedmann
    • wriedmann's Avatar


  • Posts: 3094
  • 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
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    Moderators: wriedmann