Hallo Palladin007,

braucht man Reset(), was ich persönlich bisher noch nicht hatte.

I.d.R. braucht man das auch nicht.
Aber wenns der Iterator gecached werden soll, so lässt sich per Reset der Zustand zurücksetzen bevor in den Cache kommt. Das ist aber schon eher ein Sondefall...(hab das selbst auch erst einmal so verbaut)

mfG Gü

Hallo JayDee72,

setzt doch einfach mal die Umgebungsvariable ASPNETCORE_ENVIRONMENT=Development und schau dir den Fehler an.

Greift die App auf eine Datenbank zu? Passen dort die Zugriffsrechte?
Dateizugriffsrechte, usw. Das sind die üblichen verdächtigen.

Außerdem teil uns doch mit wohin und wie die App veröffentlicht wird. Raten können wir schon, aber obs zielführen ist...

mfG Gü

Edit: race condition mit Abt, er hat gewonnen 😃

Hallo,

gut dass es jetzt wenigsten passt und Danke dass das hier gepostet wurde.

VS ist manchmal wirklich eigenartig...die Reihenfolge der Projekte sollte eigentlich egal sein, da ja "nur" eine In-Memory Repräsentation aufgebaut wird.

Solltest du dennoch (irgendwann) weitere Ursachen für das Problem eruieren können, so wäre es super wenn auch diese Ergebnise hier präsentiert werden können.

mfG Gü

Hallo Michael Hößel,

ich tippe dass irgendeine Erweiterung / Extension das Problem ist.
Versuch mal VS ohne Erweiterungen zu starten.

mfG Gü

Hallo pollito,

noch ein kleiner Tipp: die Condition in MsBuild (die *.csproj ist im Grunde eine Projekt-Datei für MsBuild) kann vereinfacht werden:

 <PropertyGroup Condition="'$(Configuration)'=='Debug'">
   <DebugType>full</DebugType>
 </PropertyGroup>
 <PropertyGroup Condition="'$(Configuration)'=='Release'">
   <DebugType>none</DebugType>
 </PropertyGroup>

Hier könnte auch z.B. für Debug die Condition ganz wegfallen, d.h. es wird zuerst der Wert für alle Konfigurationen gesetzt (es kann ja auch mehr als Debug und Release geben), dann für Release wird er überschrieben.

mfG Gü

Hallo pollito,

dann lösch die App.config einfach (wenn eh nichts drin ist).

mfG Gü

Hallo Th69,

da die Konsumentenseite wesentlich vereinfacht wird und dort keine expliziten Callbacks / Handler nötig sind.

mfG Gü

Hallo AceTecNic,

warum verwendest du jetzt den BackgroundWorker wenn doch oben ein Beispiel für Tasks gegeben ist.
Noch dazu wäre es dann besser wenn die Logik für die Druckkraft komplett von der UI entkoppelt wird und dann sollte der BGW nicht mehr bekannt sein. Außerdem kann die Task-Variante per Unit-Tests leicht(er) geprüft / validiert werden als mit dem BGW. Dieser macht vor knapp 20 Jahren sinn als es Tasks noch nicht gab.

mfG Gü

Hallo cprogrammer,

der Sinn eines Forums ist es bestimmt nicht leicht zugängliche, leicht findbare Dokumentation zu ersetzen.
Hättest du nur ein wenig die Grundlagen von C# und .NET erlernt, und dabei sprechen wir nicht von Jahren, sondern Stunden, Tage, etc. so erübrigen sich diese Fragen.

Bedenke auch dass hier im Forum alle freiwillig dabei sind. Daher ist es fast schon ein wenig unverschämt die Last etwas zu recherchieren auf die Community umzuwälzen.
Dein Umgangston bzgl. T-Virus finde ich hier nicht OK, denn immerhin hat er sich die Mühe gemacht und für dich ein paar Links rausgesucht.

Alleine die Frage "nach dem mergen von C# und C++ DLL" zeigt, dass das Konzept von .NET mit der managed Runtime noch nicht angekommen ist. Das wird übrigens in der .NET Doku recht am Anfang schon erörtert...

mfG Gü

Hallo AceTecNic,

mit einem Ereignis (event) "zerreißt" du den Codefluss.
Eine andere Möglichkeit, v.a. wenn eh ein separater Thread verwendet werden soll ist die Verwendung von Tasks und hier besonders unter Zuhilfenahme einer TaskCompletionSource.

Ganz grob skizziert so:

const int MaxSecondsToWaitForCondition = 100;
Func<bool> conditionToCheck = () =>
{
    Thread.Sleep(500);
    return true;
};

// irgendein Code

using CancellationTokenSource cts = new(TimeSpan.FromSeconds(MaxSecondsToWaitForCondition));
Task waitForConditionTask = WaitForConditionAsync(conditionToCheck, cancellationToken: cts.Token);

// anderer Code

await waitForConditionTask;

static Task WaitForConditionAsync(Func<bool> condition, int pollDelayMillis = 100, CancellationToken cancellationToken = default)
{
    TaskCompletionSource tcs = new(TaskCreationOptions.RunContinuationsAsynchronously);

    Task.Run(async () =>
    {
        try
        {
            while (!condition())
            {
                await Task.Delay(pollDelayMillis, cancellationToken).ConfigureAwait(false);
            }

            tcs.SetResult();
        }
        catch (OperationCanceledException ex)
        {
            tcs.SetCanceled(ex.CancellationToken);
        }
    }, cancellationToken);

    return tcs.Task;
}

mfG Gü

Hallo Sandmann,

if(Assembly.GetAssembly(typeof(T)) is Assembly assembly)

Hier hast du Patterrn Matching für die null-Prüfung elegant gelöst bzw. sinnvoll kombiniert.

Allerdings könnte das auch so geschrieben werden:

Assembly assembly = typeof(T).Assembly;

das spart den null-Check.

mfG Gü

Hallo cprogrammer,

was scheinbar bullet proof ist.

Ist es nicht.
Sobald der Code ausgeführt wird, lässt sich das mit einem Debugger rekonstruieren. "Bullet proof" geht hier nicht, aber das solltest du über die Forensuche, etc. schon gefunden haben 😉

wäre zu Lehrzwecken schon recht interessant ?

Ein gut gemeinter Rat: zu Lehrzwecken wären die Grundlagen von C# / .NET interessanter als irgendwelche komischen Dinge die eh nicht funktionieren.

mfG Gü

Hallo sbsbsbsb,

wenn die Kommunikation später auch über einen Server im Internet laufen könnte

Da hast du zwei eher gegensätzliche Anforderungen:

• einmal etwas Peer-to-Peer-artiges
• einmal (Zitat) eine Client-Server-Architektur

Ich würde mich gleich für letzteres entscheiden (unter der Annahme dass die Anzahl der Clients nicht sehr groß sein wird), da so auf dem Server z.B. SignalR laufen kann (ASP.NET Core). Die Clients sind dann flexibler, denn existiert für viele Plattformen entsprechende Client-Libraries.

Alternativ kann auch gRPC mit Streaming verwendet werden, dort existieren für noch mehr Plattformen die Libraries.
Mit gRPC wäre auch das Peer-to-Peer artige Szenario möglich.
Allerdings sind hier Sachen wie Broadcasts etwas schwieriger umszusetzen als bei SignalR.

Möglich wäre auch etwas eigenes basierend auf UDP zu erstellen, sofern die Nachteile von UPD (bitte selbst recherchieren) nicht gravierend sind.

Eine Instanz mach einen Server auf

Hört sich erstmal recht einfach an, aber zuverlässige Leader Election ist nicht so trivial wie es klingt.
Das ist mit ein Grund warum ich Cleint-Server-Architektur bevorzugen würde.

mfG Gü

Hallo rockxk,

Die Anwendung benötigt die vcredist_x86.exe Runtime als Vorraussetzung.

Dann wissen wir einmal dass es eine 32-bit native Windows Anwendung auf Basis der C++ Runtime ist.
Wenn du die C++/CLI Variante probierst, achte daher auf 32-bit Einstellung.
Ich vermute der Weg via NativeAOT wird hier hingegen nicht klappen, da der Office-Teil eher nicht dazu bereit ist. Sonfern also ein Test wie von Th69 vorgeschlagen klappt, so wäre das der mögliche Weg: C# / .NET Logik -> Kapselung per C++/CLI -> Einbindung ins Skript der Hauptanwendung.

mfG Gü

Hallo rockxk,

die DLL erfolgreich als Visual Studio Projekt per Reverse E. erstellen können

ist das lizenzrechtlich hier gestattet?

wird die DLL dynamisch (per Linker) angesprochen

Genau, daher heißt es ja "dynamic link library". Allerdings erledigt dieses dynamische Linken nicht ein Benutzerprogramm, sondern das Betriebssystem in Form der "Loader"-Komponente.

Mir ist die ganze Architektur hier noch unklar und du beantwortest leider die Fragen nicht. Ebenso ist es sehr hilfreich wenn du nicht beurteilen kannst ob X od. Y -- wie sollen hier hilfreiche Kommentare produziert werden?

• Ist die Hauptanwendung nativ od. managed -- also C/C++ od. C#?
• Was soll die zu ersetzende DLL genau ansprechen? Neueres Outlook...nunja das kann auch wieder Vieles sein. Falls dort wiederum Inline-Assembler nötig ist, so geht das mit C# / .NET nicht. Ist Inline-Assembler nicht nötig, so geht das womöglich (siehe Kommentare oben).

Ein Upgrade der Hauptsoftware ist aus Kostengründen (>100.000€) nicht möglich und nach heutigem Stand auch nicht mehr sinnvoll.
Ein Ersatz ebenfalls nicht, da eine ganze Produktion daran hängt.

Da habt ihr aber eine sehr weitsichtige Führungsetage. Das ist schon fast grob fahrlässig -- leider aber auch sehr oft anzutreffen.
Wir hier ernsthaft daran geglaubt, dass das System, an welchem die ganze Produktion hängt, durch Reverse Engineering, Rumbasteln an einer DLL, etc. in die Zukunft gehebelt wird?

mfG Gü

Hallo rockxk,

gehts um .NET Framework od. um .NET (Core)?
Je nachdem gibt es verschiedene Möglichkeiten, denn bei neuen Versionen von .NET kann via NativeAOT eine DLL erstellt werden, welche ein C-ABI hat ("DllExport") und dadurch könnte neben der genannten Möglichkeit mit C++/CLI auch die DLL erstellt werden.

Beim gezeigten nativen Code wird mit Inline-Assembler direkt gearbeitet, daher bedenke dass dies mit C# / .NET nicht möglich ist. Vllt. bist du besser dran wenn diese Teile in C++ bleiben? (Kann ich natürlich so nicht für dich beantworten).

Im Hauptprogramm werden diese externen Funktionen angesprochen bzw. eingebunden.

Per [DllImport] od. durch Laden der DLL?

Diese DLL soll durch eine neue ersetzt werden, wobei das Hauptprogramm, welches die DLL lädt nicht "angefasst" bzw. verändert werden kann.

Also wenn die DLL durch eine managed Komponente (C# DLL) ersetzt werden soll, so wäre es naheliegend auch im Hauptprogramm das direkt od. via "Assembly Load" anzusprechen, statt einen Umweg managed → native → managed zu gehen.
Wenn du diese Einschränkung also irgendwie ändern kannst...

mfG Gü

Hallo,

es wird wohl auch Änderungen in Roslyn und NuGet geben (müssen):

• Roslyn wird einen Analyzer nur dann ausführen, falls kein externes IO außer AdditionalFiles ausgeführt wird
• NuGet (-Server) wird beim Indizieren der Pakete auch den Code prüfen müssen und eventuell das Paket ablehnen

Das Unding von kzu wird wohl noch größere Kreise ziehen.
Schade dass der OSS-Gedanke hier so mockig behandelt wurde.

mfG Gü

Hallo cprogrammer ,

Ich vermisse hier

• etwas Eigeninitiave
• Beschäftigung mit den Grundlagen, die leicht der Doku, etc. zu entnehmen sind

Tu dir doch den Gefallen und lies dich ein. Das kostet auch viel weniger Zeit als in einem Forum solche Fragen zu stellen und auf eine Antwort zu warten.

mfG Gü

Hallo Palladin007,

so pauschal kann ich das nicht sagen, denn es hängt auch von der konkreten Anwendung* ab. Dort nehm ich dann halt das "natürlichste" wie sich das aufteilen lässt. Klar jetzt kommt die Frage: "was ist das natürlichste?" und ich würd die Antwort gleich beginnen wie diese 😉

* also jetzt nicht nur WPF mit MVVM od. sonst was, sondern obs Benutzerverwaltung, Simulationsprogramm, etc. ist

Ich würde auf jeden Fall Commands und Queries separarieren (das muss nicht unbedingt in CQ(R)S ausarten und kann auch in MVVM verwendet werden), dann hab ich schon einmal (grob) eine Aufteilung nach Use Cases.
Das Ganze dann in Verbindung mit der jeweiligen View ergibt eien Art "Feature" und dieses ist in einen eigenen Ornder / Namespace gepackt. Dort ist dann alles drin, was für dieses Feature benötigt wird und erspart die lästigen Sprünge quer durch die Solution, so ist es leichter zu verstehen da zusammengehördende Dinge auch nah beinander liegen. Größere Projekte lassen sich so auch recht elegant umsetzen, ohne dass alles irgendwie fragil erscheint und sich keiner mehr auskennt.

mfG Gü

Hallo teebeast,

Darf auch gerne allgemein gehalten sein

grundsätzlich ist zwischen Anwendungsentwicklung und Library-/Framework-Entwicklung zu unterscheiden, da beide Gruppen verschiedene Ziele verfolgen. Hier gehts um die Anwendungsentwicklung und da halte ich es "nicht so abstrahiert wie möglich, sondern so abstrahiert wie nötig", wobei sich das nötig mehr od. weniger von alleine ergibt um testbaren Code zu haben.

Muster (Pattern) stellen Ideale dar, welche sich im Laufe der Zeit herauskristallisiert haben. Das heißt jedoch nicht automatisch, dass jedes Muster gem. Referenzimplementierung voll und ganz umgesetzt werden soll/muss. Es sollte eher als Anleitung, grober Bauplan, Orientierung gesehen werden. Daher wenn für euer Team das funktioniert, der Code testbar ist wozu mehr Aufwand für weitere Abstraktionen betreiben?

Uns fehlen hier auch gewisse Konstrollstrukturen wie Softwarearchitekten oder Code Reviews

Das lässt sich ja ändern. V.a. mit Code Reviews kann jederzeit und leicht begonnen werden. Alleine schon durch Fragen wie "warum wurde das so gelöst" kann innerhalb des Teams eine interessante Diskussion entstehen, bei deren Ende alle der Diskussion teilhabenden mehr Verständnis für die Lösung haben, die u.U. letztlich ganz anders aussehen kann.
Code Reviews sind nicht nur Kontrolle, sondern auch Lernen und Verstehen.

Der UI-Bereich besteht nun aus mindestens vier Assemblies

Ist das nicht eine künstliche Einschränkung dass es "mind. vier Assemblies" sind? Das führt ja zwangsläufig zu

merke aber dass ich erhebliche Probleme habe, mich im Quellcode zu orientieren.

und den weiters angeführten Problemen. Zudem hat das großes Fehlerpotential, da auf einem Blick die Zusammehänge wohl kaum überschaubar sind.
Probier mal -- z.B. in einem Test-Projekt -- die "Bestandteile" von MVVM näher zusammenzurücken, z.B. in einem Unterordner im Projekt. Dann ist die Orientierung im Code leicht, das Verständnis was der Code tut ebenfalls leicht überschaubar. Änderungen und Weiterentwicklungen gehen dann zügiger voran, da eben das Verständnis vorhanden ist und nur in einem Ordner gewert werden braucht, anstatt in 2, 3, 4 Assemblies wo fast niemand genau weiß warum dort.

Sollte dann z.B. das Model woanders auch benötigt werden, also falls sich dieser Fall tatsächlich ergibt, so kann das ja verschoben werden.
Aber von vornhinein würde ich (heute) keine Projekte mehr zwangsmäßig in (thematische) Assemblies aufteilen (XYZ.View, XYZ.ViewModel, XYZ.Models, etc.), sondern das nach Anwendungsfällen (use cases), Benutzeraktionen, usw. aufteilen.

mfG Gü

Hallo,

Zeigeroperationen fallen unter "unsafe code"

Und das zu recht, denn C# (zusammen mit .NET als Runtime) garantiert die sichere Ausführung vom Code, d.h. es gibt keinen Buffer-Überlauf, keine Zugriffsverletzungen durch Lesen/Schreiben außerhalb vom zulässigen Speicherbereich (wie Arrays), usw.
Es wird z.B. eine IndexOutOfRangeException erzeugt falls der Index nicht innerhalb des gültigen Bereichs ist, anstatt eine "Access Violation" zu erzeugen od. überhaupt den falschen Speicherbereich zu lesen, welches auch ein Sicherheitsrisiko darstellt.

Außer es wird explizit "unsafe code" aktiviert, so ist für die Code-Bereiche, welche per unsafe markiert wurden, der Programmierer selbst in der Verantwortung das Richtige zu tun ("allows to shoot oneself in the foot").

BTW: im modernen .NET gibt es die Unsafe und MemoryMarshal Klassen, welche eigentlich auch als "unsafe code" gelten, nur momentan keinen entsprechenden Compiler-Switch benötigen. Dazu gibt es aber einen Vorschlag dies zu ändern (welchen ich unterstütze).

Ist bei C# das Thema "Zeiger" überhaupt noch ein Thema oder muss man sich darum gar nicht mehr kümmern ?

Zeiger sind in C#

• für Anwendungsentwicklung so gut wie nie nötig -- außer es wird per Interop mit nativem Code zusammengearbeitet
• für low-level Bibliotheks-Code (z.B. String-Handling) teilweise nötig um Tricks, welcher C# so nicht zulassen würde, zu verwenden damit auf diesen unteren Schichten des Runtime-Stacks optimale Performance vorhanden sein kann

Da der Großteil der Programmiertätigkeit wohl eher in den Bereich der Anwendungsentwicklung fällt, Zeiger in C# ein fortgeschrittenes Thema sind, rate ich dir diese erstmal zu vergessen. Du wirst mit C# / .NET Bordmitteln das Ausreichen haben (sofern die Grundlagen und Konzepte von .NET sowie C# verstanden wurden).

mfG Gü

Hallo JayDee72,

Ich möchte z.B. mit dem ermittelten Namen auf das AD zugreifen....

Kannst du beschreiben was du damit genauer machen willst?
Oft ist ein direkter AD-Zugriff nicht nötig, sondern die relevante Infos können anders ermittelt werden.

Außerdem ist das eine Blazor-App (?), da würde ich so od. so nicht direkt aufs AD zugreifen wollen (zwecks Sicherheit). Besser wäre da den AD-Zugriff via Backend-API zu erledigen.

mfG Gü

Hallo Micha21tts,

noch als kleiner Hinweis da es um Distanzvergleiche geht: die Wurzelfunktion ist streng monoton, daher gilt sqrt(x) < sqrt(y) => x < y. D.h. es ist nicht nötig die Wurzel zu berechnen, da diese aufwändig ist. Z.B. im Projekt, das T-Virus verlinkt hat, braucht es hier keine Wurzel, es genügt mit dem quadratischen Abstand weiter zu rechnen.

Abgesehen davon und sollte es zu Lern-/Übungszwecken dienen, so würde ich versuchen den Algorithmus zu verstehen und dann selbst umzusetzten. Falls du dann dabei irgendwo hängst, so können wir weiterhelfen, nicht jedoch als allgemeiner Codelieferant 😉

mfG Gü

Hallo Kriz,

schau dir dazu Configuration an und dazu auch Environment.

Damit bleibt der Code "schön" (ohne die Präprozessor-Direktiven) und jeweiligen Einstellungen (ConnStrings, etc.) können in Abhängigkeit von der Umgebung (Environment) geladen werden.
So ist auch lokales Testen, Testen in CI, Staging, Produktion, etc. einfach und ohne Änderung im Code möglich.

mfG Gü

Hallo,

der Sharplab Link suggeriert dass beide Varianten zu gleichem Code kompiliert werden. Tatsächlich wird der C#-Code vom Compiler zu IL kompiliert und dort sind die Unterschiede (Variante A / B) zu sehen.
Für den C#-Reiter in Sharplab wird zwar gleicher Code angezeigt, da Sharplab intern das IL zu C# zurückführt (und hier wohl eine semantisch korrekte Repräsentation zeigt, jedoch keine 1:1 Repräsentation).

BTW: Lowering hat mit dieser "Umwandlung" nichts zu tun -- lowering wäre z.B. foreach über Array → for-Schleife usw.

Gibt es hier ein BestPractice?

Sehe ich wie T-Virus. Argument-Validation zu Beginn der Methode und dann entweder entsprechende Fehler schmeißen od. aus Methode aussteigen.

Hat eine der Versionen Performance-Vorteile?

Ist das relevant?
Und falls ja, so spätestens mit .NET 8 nicht mehr, denn dort ist die sogenannte dynamische profilgestützte Optimierung (D-PGO) des JIT aktiviert und dadurch erzeugt der JIT Maschinencode in Abhängigkeit vom tätsächlichen Programm-Ablauf.
Hier im Beispiel (egal ob Variante A od. B) falls x nie od. zumindest selten (< 50 %) null ist, so wird der Block für "null-Fall" in den "kalten" Bereich der Method geschoben. Kurz: die Performance ist in beiden Fällen gleich.

Wie die Frage nach der "Relevanz" schon angedeutet hat, würde ich mir darüber keine Gedanken machen und v.a. den Code leserlich schreiben.
Sollte Profiling, etc. zeigen dass diese Methode kritisch ist, dann (und "nur dann") ist es sinnvoll diese zu optimieren. Ein paar Tricks gibt es dazu.

Wobei ab .NET 7 Leserlichkeit und Perf Hand in Hand gehen bei ein paar Exceptions.
Vor .NET 7:

public int Foo(object x)
{
    if (x is null)
    {
        throw new ArgumentNullException(nameof(x));
    }
    
    return x.GetHashCode();
}

Ab .NET 7:

public int Foo(object x)
{
    ArgumentNullException.ThrowIfNull(x);
    
    return x.GetHashCode();
}

Der Code wird IMO leserlicher und es zugleich weniger Maschinencode vom JIT erzeugt.

Anmerkung: im Beispiel ist das Argumnet object x und nicht object? x (also mit nullable annotations). Da Foo eine public Methode ist und x eben nicht als null erwartet wird (daher keine Annotation) muss auch das Argument validiert werden -- sprich ein Fehler erzeugt werden, falls es doch null ist.
Anders ist es bei folgendem Beispiel:

public int Bar(object? x)
{
    return x is not null
         ? x.GetHashCode
         : 0;    // od. welcher Wert auch immer für `x is null` verwendet werden soll
}

Hier wird null erlaubt, daher muss null auch toliert werden und ein Ergebnis ohne Fehler (Exception) zurückgegeben werden.

Insofern kann ich

keine Null-Checks mehr, außer ich markiere den Parameter als nullable, dann zwingt (wenn ich es als Fehler behandeln lasse) der Compiler mich dazu.

nicht richtig einordnen. Vllt. ist es richtig gemeint od. auch nicht. Jedenfalls so wie ich es beschrieben haben ist es im Sinne von Nullable-Annotations.

Im private oder internal Code schreibe ich persönlich gar keine Null-Checks mehr

Das hat eigentlich noch nie wirklich Sinn gemacht (also Null-Checks in nicht öffentlichen Methoden), da diese ja nur von public Methoden aufgerufen werden können (direkt od. indirekt). Um dennoch potentielle NullReferenceException vorzubeugen kann man

/* internal od. */ private int Foo(object x)
{
    Debug.Assert(x is not null);
    
    return x.GetHashCode();
}

schreiben. Dann wird zumindest beim Debuggen od. falls CI/CD mit einem Debug-Build die Tests auch durchführt dieses Assert ausgeführt. Im Release-Build wird dieses Assert vom C#-Compiler weggelassen, daher auch keine negativen Effekte für die Perf.

mfG Gü

Hallo cprogrammer,

ergänzend zu Abts Antwort uns falls es wirklich ums statische "Linken" gehen soll, dann siehe Native AOT.

Neben deiner anderen Frage, stellt sich mir jedoch die Frage "wozu das Ganze"?
Steckst du gedanklich in C/C++ fest und hast den Sprung zu managed Sprachen / Runtimes wie C# und .NET noch nicht vollzogen?

mfG Gü

Hallo Christoph K.,

Gibts es hierzu schon irgendetwas vorgefertigtes?

Schau dir dazu einmal Roslyn Analyzers an. Damit kann direkt per API vom Compiler gearbeitet werden und somit der (geparste) Syntaxbaum auch verändert werden (via Fixer). Das ist dafür gedacht -- ich vermute mit Regex wirst du viel mehr falsch positive Treffer erhalten.

mfG Gü

Hallo Christoph K.,

Dies geht ja nun nicht mehr, und mann muss alle Parameter in einer Klasse kapseln und dann in Form eines Parameters + dem Attribute [FromBody] in die Parameterliste schreiben.

Schau dir dazu Binding source parameter inference an.

mfG Gü

Hallo pollito,

ich verwende Code alignment
Und dank der Shortcuts, die konfigurierbar sind, geht das ruckzuck.

mfG Gü

Hallo,

vor lauter Klammern und vielleicht | Verknüpfungen ein ! untergehen sieht

Hängt natürlich vom konkreten Fall ab, aber das könnte auch in eine lokale Funktion (ab C# 7) ausgelagert werden, dann ist es übersichtlich und u.U. das ! auch nicht mehr nötig.

mfG Gü

Hallo,

bei einem bool finde ich if (bedingung == true) / if (bedingung == false) unsinnig, da eben durch das bool dies schon eindeutig ist. Den Punkt bzgl. Lesbarkeit, v.a. bei Personen mit Sehschwäche, lass ich gelten, aber hier sollte m.E. eine Extension im Editor das optisch besser darstellen als unnötigen Code zu schreiben.

Anders bei bool? / Nullable<bool>. Um nicht mit Konstrukten wie GetValueOrDefault(false), ?? false, etc. hantieren zu müssen, kann das ein if (nullableCondition is true) durchauch hilfreich sein.
Das is true würde ich aber nicht bei if (nonNullableCondition) verwenden, alleine um dort schon den Unterschied zwischen bool und bool? deutlicher parat zu haben.

Lesbarkeit als sehr wichtig

Stimmt, v.a. da Code i.d.R. öfter gelesen als geschrieben wird.
Für mich ist jedoch == false nicht lesbarer, es stört vielmehr. Daher lässt sich auch über den Punkt Lesbarkeit diskutieren.

mfG Gü

Hallo Caveman,

die vorgestellte Lösung funktioniert, jedoch sollte bei Algorithmen auch die Aufwandsklasse berücksichtigt werden. Hier ist diese recht hoch. Bei kleinen Mengen mag das kein Problem darstellen, aber es gibt effizientere Lösungen wie jene von BlonderHans od. via HashSet.

mfG Gü

Hallo 4noxx,

am einfachsten und mit .NET-Klassen geht via HashSet. Schau dir diesen Typ einmal an und du siehst die zur Verfügung gestellten Mengenoperationen.

Wenn du es jedoch -- zu Lernzwecken -- lieber händisch durchprogrammieren willst, so ist ein naiver Ansatz einfach für jedes Element der einen Liste in der Zielliste zu Suchen ob es dort vorhanden ist od. nicht. Entweder (ganz) naiv per verschachtelten Schleifen od. etwas besser über die Array.Find-Methode.

Probiers einmal aus, falls du hängst helfen wir gerne weiter.

mfG Gü

Hallo sv00010kas,

falls in deinem Browser noch so ist, kannst du bitte einen Screenshot anhängen?
Wäre interessant wie das aussieht.

mfG Gü

Hallo Sandmann,

super, das ist auch viel effizienter als mein Versuch. Im Bild unten deine Variante.

mfG Gü

Hallo ThomasE. ,

angenommen die Tabelle heißt Foo, dann z.B. mittels Common Table Expression und Cross Apply:

with cte as
(
    select  f.Id, f.Nr
    from    Foo f
    group by f.Id, f.Nr
)
select  t.*
from    cte c
cross apply (
    select  top 1 *
    from    Foo f
    where   f.Id = c.Id
        and f.Nr = c.Nr
    order by f.IsSet desc
) t

Geht vermutlich effizienter...

mfG Gü

Hallo zusammen,

ab C# 7 kann mittels Pattern Matching der Code auch als

if (bedingung is true)
{
    // ...
}

// Oder

if (bedingung is false)
{
    // ...
}

mfG Gü

Hallo P.St. ,

das Projekt auf .Net Framework 4.8.1 migriert

Warum nicht .NET 6 (LTS) od. .NET 7 (STS)?
Da wird Arm auch besser unterstützt als bei .NET Framework 4.8.1. Wenn schon migriert wird, so schau dir doch die neueste Version von .NET (aktuell 7, .NET 8 gibts als Preview) an. Zusätzlich bietet der JIT und die Libraries dort mehr Optimierungen für Arm an, so dass zusätzlich der Code effizienter abgearbeitet wird.

mfG Gü

Hallo T-Virus,

Bei ARM beziehe ich mich mehr auf die Sparsamkeit im Leerlauf als auf die Performance.

Dann schreib das doch gleich 😉
Bisher war die Argumentation nicht sehr schlüssig, eher lose Aussagen.

Mir gehts nicht um die eine od. andere Seite (x86 od. Arm), da ich je nach Anwendungsfalls die ein od. andere Technologie passender halte, sondern darum dass die getätigten Aussagen auch entsprechend arguemntiert werden (das gilt nicht nur für dich).

Bei dem Umweltthema muss man halt auch beachten, dass die Hardware zum ersetzen auch erstmal gebaut werden muss.

Da stimme ich zu.
Vom eigentlichen Thema "Transition von x86 auf Arm" rutschen wir schon ein wenig ab, aber in "Smalltalk" ist das nicht so streng...
Beim Umweltthema könnte auch schon viel getan werden, wenn viel unnötiges Streaming, Social-Media stark reduziert werden würde. Da geht es oft nur um "Müll" den eh keinem interessiert, aber TB an Daten produziert werden.

Auch wenn ich jetzt selbst vom Thema abgewichen bin und die Tür für eine weitere Diskussion geöffnet habe, sollten wir versuchen beim Haupt-Thema Arm <-> x86 zu bleiben.

mfG Gü

Hallo T-Virus ,

Insgesamt ist ARM hier definitiv sparsamer.

Auf Grundlage von was? Bzw. welcher Benchmark liegt dieser Aussage zugrunde?

So allgemeine Aussagen sind für mich schlichtweg nicht treffend, ich bin fast bereit zu schreiben "falsch".
Es hängt doch sehr wohl auch von der zu betrachtetenden Workload ab und wenn so eine Aussage getroffen wird, so sollte diese Workload ev. zusammen mit Quellen auch angegeben werden. So ist das Argument wertlos.

• ARM CPUs haben ihre Vorteile in gewissen Anwendungsfällen
• x86 CPUs haben ihre Vorteile in gewissen Anwendungsfällen
• Custom Design Chips haben ihre Vorteile in gewissen Anwendungsfällen (Microsoft zB mit eigenem Ampera Chip in Azure, bzw. FPGA für Networking und AI)

Sehe ich auch so und nicht (vereinfacht) "Arm = gut, x86 = schlecht".

In Bezug auf .NET finde ich es super, dass Arm genauso berücksichtigt und optimiert wird wie für x86. Das lässt jedoch auch keine Aussage über die Effizient / Umwelteinfluss von Arm <-> x86 zu, denn im Bereich Software hängt es v.a. davon ab wie effizient der Code arbeitet und hier spielt auch die O-Notation und geeignete Datenstrukturen eine große Rolle. Einen Einblick gibt hier Sustainable Code.

Da du den Bogen auf CO2 und Verkehr / Industrie gespannt hast, sollte das auch nicht "zuerst Verkehr / Industrie, dann CPU / SW" sein, sonder idealerweise "jeder optimiert sich, denn auch kleine Beiträge bewirken in Summe etwas" sein.

mfG Gü

Hallo P.St. ,

alle x86-Systeme ersetzt werden ..., unserer Umwelt zuliebe

Kannst du diese Aussage begründen?
Ich finde "x86 ~ nicht gut für die Umwelt" etwas vereinfacht.

werde ich auf die aktuelle Version 4.8.1 migrieren

Falls schon migriert wird, so schau dir auch .NET 7 bzw. Erste Preview von .NET 8 an.
Dort ist die Unterstützung für Arm(64) wesentlich besser. Da es insgesamt, also auch für x86, Verbesserungen zu .NET Framework (4.x) gab sollte das der Umwelt auch zu liebe kommen.

mfG Gü

Hallo BlueSubmarine,

Es soll aber immer nur ein Task gleichzeitig laufen.

Das lässt sich i.d.R. durch andere Architekturen besser lösen, wie auch Abt erwähnt.
Z.B. mittels Channels lässt sich ein Producer/Consumer sehr effizient und einfach umsetzen.

Sollte die Anforderung dennoch "nur ein Task gleichzeitig" sein, so lässt sich das via eigenem

Hallo oehrle,

hast du dir die Fehlermeldung auch durchgelesen? V.a. die InnerException? Hier nochmal der Einfachheithalber:

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. 10.38.143.27:27017

Ist also die DB erreichbar? Firewall, etc. gestattet den Zugriff? Kann z.B. via Robomongo auf die DB zugegriffen werden usw.

mfG Gü

Hallo oehrle,

tritt ein Fehler auf

Du bist ja nicht erst seit Kurzem beim Forum dabei und wohl auch als Entwickler tätig. Daher solltest du auch wissen dass "ein Fehler" eine sehr exakte Beschreibung vom Problem ist, bei der sich jeder sofort auskennt und zielgerichtet eine hilfreiche Antwort verfassen kann. Oder auch nicht...

mfG Gü

Hallo Alf Ator,

gRPC.

Schau dir das einmal an, mehr schreib ich jetzt nicht 😉

mfG Gü

Hallo Jonas2909,

Gibt es eine Möglichkeit eine Methode für alle Objekte aufzurufen?

Speichere alle Menschen in einer Liste, dann kannst du z.B. mit foreach über diese Liste iterieren und für jedes Menschen-Objekt die Methode aufrufen.

public class Welt
{
    private readonly List<Mensch> _menschen;

    public void BewegeAlleMenschen(/* ... */)
    {
        foreach (Mensch mensch in _menschen)
        {
            mensch.Bewege(/* ... */);
        }
    }
}

BTW: [Tipp] Anfängerhinweis == true / == false

mfG Gü

Hallo C4RL0,

Gibt es Frameworks ... die soetwas unterstützen ...

Ja gibt es, aber das hängt von den Rahmenbedingungen ab, also ob ein solcher Einsatz möglich ist od. nicht. Wegen

I.d.R. arbeite ich mit Windows Forms.

gibt es irgendwelche Beschränkungen, Voraussetzungen, etc. die du uns mitteilen solltest? Z.B. es muss auf einem Server in eurer Firma laufen, kann in der Cloud sein, Clients sind alle WinForms od. nicht, Datenbank muss SQL Server sein od. nicht. Usw. denn danach richten sich auch die möglichen Empfehlungen / Tipps.

Nach "workflow engines" hast du sicher schon gegooglet 😉

mfG Gü

Hallo,

Wobei ein Umstieg eigentlich kaum Probleme machen dürfte.

Für "normale" Anwendungen sollte es keine Problem geben, da wie immer sehr hoher Wert auf Abwärtskompatibilität gelegt wird / wurde. Ganz klappt das jedoch nicht immer, daher zeigt Breaking changes in .NET 7 eine Übersicht davon.

Hat sich ggf. noch bei der Performance mit .NET 7 geändert oder läuft noch alles gleich flink?

.NET hat ein sehr intensives Perf-Lab indem fast permanent Benchmarks laufen um eventuelle Regressionen frühzeitig entdecken zu können.
.NET 7 ist in vielen Bereichen schneller als bisherige .NET-Versionen, zumindest jedenfalls nicht langsamer. Details dazu im Link, den Abt gepostet hat.

Wichtiger finde ich jedoch die Menge an neuen APIs und C#-Möglichkeiten, die es uns allen gestatten eleganteren / effizienteren Code zu schreiben 🙂

mfG Gü

Hallo Little Tester ,

bekommen, also "get". Ich will die Variable dann nicht mehr verändern, weil ich ja die Information dann habe die ich brauche.

Das passt so und das Objekt ist dann "immutable", kann also nicht mehr verändert werden.
Die Werte der Eigenschaft kann im Konstruktor gesetzt werden.

public class Person
{
    public string Name { get; set; }
    public Date Birthdate { get; }

    public Person(string name, Date birthdate)
    {
        Name = name;
        Birthdate = birthdate;
    }
}

Name hat Getter und Setter, da sich der Name z.B. durch Heirat, Namensänderung ändern kann.
Birthdate kann sich aber nicht ändern, daher nur ein "Getter".
Um die Werte zu setzen, werden diese während der Konstruktion des Objects im sog. Konstruktor gesetzt.

mfG Gü

Hallo dr4g0n76,

Fuzzing benutz ich bei Parsern die "untrusted input" haben und von byte / char -> T gehen.
Da kann es schon sein, dass ein paar Kombinationen der Bytes (im hohen UTF-8 Bereich) dabei sind, an dene ich bei Unit-Tests nicht gedacht habe. Durch das Ergebnis einer solches Fuzz-Session wenn etwas gefunden wurde, können die Unit-Tests nachgerüstet werden.

Ich seh Fuzzing dennoch eher als Nische und nur für spezielle Anforderungen, wie eben Parser, sinnvoll an.
Wobei mit "Parser" auch das Lesen einer Befehszeile, einer Konfig gemeint sein kann. Bei diesen Beispielen würde ich aber sowieso auf die .NET Infrastruktur aufbauen und vertrauen dass es passt (dort könnte Fuzzing wiederum angewandt werden).

Der Aufwand an sich um Fuzzing zum Laufen zu bringen ist nicht recht hoch, aber die Dauer einer Fuzz-Session i.d.R. schon (etliche Stunden und mehr).
Nur bei trivialen Bugs kann der Fuzzer recht schnell einen Treffer finden -- das ist aber stochastitisch und nicht deterministisch, je nachdem welche Seed für die Mutationen, etc. verwendet wird.

Also kurz: finde ich sinnvoll, aber nur für wenige spezielle Anforderungen.

WinDbg verwende ich nicht (direkt). Wenn schon dotnet-dump und den dortigen SOS Befehlen.

mfG Gü