Guten Tag,

ich setze SignalR in einer ASP.NET Core 6 Anwendung ein. Zur Authentifizierung einer neuen Connection wird KeyCloak verwendet.

Wenn ich nun vom Client aus eine Connection zum Hub aufbauen möchte, dann funktioniert das mit dem KeyCloak AccessToken ohne Probleme. Wenn dieses Token nun aber abläuft, dann bleibt die SignalR-Verbindung aber trotzdem bestehen. Genau das möchte ich aber verhindern.

Ich habe nun gesehen, dass es eine erweiterte Option bei SignalR namens "CloseOnAuthenticationExpiration" gibt. Diese klingt so, als wäre sie genau das was ich brauche. Ich habe diesen Wert bei mir in der Testumgebung folgendermaßen gesetzt:

app.UseEndpoints(endpoints =>
    {
        endpoints.MapHub<v1.NotificationHub>("/v1/notificationHub", options =>
        {
            options.CloseOnAuthenticationExpiration = true;
        });
        endpoints.MapControllers();
    });

Leider wird die Connection nach Ablauf der Tokengültigkeit nicht geschlossen.

Hat vielleicht einer Erfahrung mit diesem Thema und kann mir sagen, welche zusätzlichen Dinge ich noch implementieren muss, damit diese Option greift?

@BerndFfm: Mit welchem "Scripting-Host" werden die Skripte denn geladen bzw. ausgeführt und unterstützt du das Laden von 3rd Party Libraries (durch Referenzen auf die Assemblies) oder muss sich das Skript da selbst drum kümmern?

@T-Virus: Aktuell wäre der Plan, zur Laufzeit an einer bestimmten Stelle im Code nach [BestimmterOrdner][BestimmterDateiname].cs zu suchen. Falls diese Datei existiert, sollte ein ScriptingHost die Datei laden und eine gewünschte (hoffentlich vorhandene Methode) ausführen.

Der Kunde könnte im Endeffekt selbst Hand anlegen und z.B. hauseigene Bibliotheken zur Ver-/Entschlüsselung von Inhalten zwischen schalten.

Das mit dem Scripting ist nur aufgekommen, da das Produktmanagement meint, es wäre für die Kunden bzw. unsere Consultants einfacher mal eben in einer kundenspezifischen Programmierung ein Skript anzupassen, anstatt eine DLL zu kompilieren.

Ich selbst bin ein Freund der Plug-in Lösung. Allerdings kann ich auch die Einfachheit der Skript-Lösung nachvollziehen.

Ich bin soeben über "CS-Script" gestolpert.
Das könnte mich schon ein ganzes Stück weiter bringen, wenn es hält was es verspricht.

Ich muss mir das mal anschauen...

Danke für die bisherigen Antworten!

@Abt: Bisher wurden diese Probleme tatsächlich mit VB-Script gelöst. Da gab es keine Assemblies die in App-Domains geladen werden und OOP bis ans Limit.

Da das Kernprodukt in C# entwickelt wurde und die meisten Entwickler innerhalb der Firma auch C# beherrschen, wollte man am liebsten in dieser Sprache bleiben.

Vielleicht ist der Ansatz aber auch einfach verkehrt. Ich versuche das ursprüngliche Problem mal zu schildern...

Innerhalb des C# Codes gibt es Stellen die, falls eine Implementierung für diese Stelle/Hook existiert, diese Implementierung dann auch durchlaufen werden soll. Quasi nach dem Motto: Wurde ein Handler für diesen Hook gefunden, dann rufe ihn auf und lass ihn arbeiten. Die Signaturen dieser "Erweiterungspunkte" wären wohl definiert und die Entwickler würden sich an die Konventionen halten und somit könnte die Hauptanwendung die Methode innerhalb des "Erweiterungsskriptes" finden und aufrufen. Leider sind diese "Erweiterungsskripte", wie immer, abhängig von anderen Assemblies.

Von daher sehe ich inzwischen eigentlich nur noch die Plug-in Lösung. Also die Entwickler sollen bitte sehr DLLs in nen bestimmten Ordner werfen und die Hauptanwendung scannt diese Ordner nach verwendbaren Modulen.

Ich muss wohl etwas weiter ausholen merke ich gerade....

Innerhalb des Skripts, sollen andere Entwickler ihren C# Code ausführen können, der wiederum auf andere 3rd Party Bibliotheken zurückgreifen muss.

Jetzt habe ich Ansätze wie die Roslyn Scripting API gesehen, die Code Zeile für Zeile ausführt.
Dadurch würden zur Laufzeit ja nicht automatisch die benötigten 3rd Party Assemblies geladen werden oder etwa doch?

Muss ich vielleicht doch lieber eine Assembly per AssemblyResolver als Plug-in laden und aufrufen anstatt ein Skript zu laden?

Die Skript Variante erschien mir Anfangs attraktiv, da so die anderen Entwickler für Anpassungen nicht immer erst eine Plug-in DLL kompilieren müssten, sondern den Skript-Code "mal eben" anpassen und sofort laufen lassen könnten.

Guten Tag,

ich schaue mich gerade nach einer Möglichkeit um, mit der ich zur Laufzeit ein externes C#-Skript (liegt im Dateisystem in einem zugreifbaren Ordner) laden und Methoden innerhalb dieses Skripts ausführen kann.

Also z.B. würde das Skript folgende Methode enthalten, die ich gerne zur Laufzeit aufrufen würde:

public Task<object> Execute(object parameter) {}

Nun finde ich Beiträge im Netz von 2010, in denen z.B. der Typ Microsoft.CSharp.CSharpCodeProvider verwendet wird um den Code zu laden und on-thy-fly zu kompilieren.

Ist es aktuell immer noch der Weg den man gehen sollte oder hat sich in der Zwischenzeit da etwas getan und ich würde auf das falsche, schlecht gealterte, Pferd setzen? Vielleicht gibt es inzwischen bessere (Standard-) Bibliotheken?

Gruß

Hallo zusammen,

ich möchte in meinem Setup Projekt in einer Custom Action den Inhalt einer (durch den Installer) installierten Datei lesen und verwenden. Wenn bei dieser Custom Action ein Fehler auftritt, möchte ich die komplette Installation des Produkts rückgängig machen, also das es später nicht unter den installierten Programmen erscheint.

Ich habe nun das Problem das ich den Inhalt der Datei erst nach dem "InstallFinalize" event von der Platte lesen kann und wenn ich nun die Custom-Action einen Fehler werfen lasse, hat das keine Auswirkung auf die Installation. Sprich, die Dateien bleiben an Ort und Stelle und es erscheint natürlich auch unter den installierten Programmen.

Laut Doku wird mein gewünschtes Verhalten anscheinend auch nicht unterstützt.

Nun hoffe ich auf viele pfiffige Entwickler, die es vielleicht doch irgendwie hinbekommen haben oder 'nen Workaround gefunden haben?

Gruß
wax

Bringt leider keine Besserung.

Hier nochmal die Auszüge aus der web.config Datei:

<behaviors>
    <endpointBehaviors>
        <behavior name="webServiceEndpointBehavior">
            <AuthenticationBehaviorExtensionElement />
            <FluentValidationBehaviorExtensionElement />
        </behavior>
    </endpointBehaviors>
    <serviceBehaviors>
        <behavior name="serviceBehavior">
            <serviceDebug includeExceptionDetailInFaults="true" />
            <serviceMetadata httpGetEnabled="true" />
        </behavior>
    </serviceBehaviors>
</behaviors>

<bindings>
    <basicHttpBinding>
        <binding name="http" textEncoding="utf-8">
            <security mode="TransportCredentialOnly">
                <message clientCredentialType="UserName" />
            </security>
        </binding>
    </basicHttpBinding>
</bindings>

<service name="FancyController" behaviorConfiguration="serviceBehavior">
    <endpoint name="fancy_httpEndpoint" behaviorConfiguration="webServiceEndpointBehavior" address="" binding="basicHttpBinding" bindingConfiguration="http" contract="IFancyControllerDTO" />
    <endpoint name="fancy_httpMetadataEndpoint" address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
    <host>
        <baseAddresses>
            <add baseAddress="http://localhost:8082/Controllers/FancyController.svc"/>
        </baseAddresses>
    </host>
</service>

Eine http-Bindung wurde im IIS konfiguriert.
Der eigentliche Service-Endpoint verwendet binding="basicHttpBinding" und eine bindingConfiguration mit den http Security-Settings.

OT: Der Kunde will... 😁

Gruß
wax