Da bin ich ja beruhigt. Allerdings scheint der Reboot die ganze Zeit sauber gelaufen zu sein.

An der Stelle habe ich keine Anpassungen gemacht und lediglich gestern mal getestet wie es sich verhält. Dachte zwar im ersten Moment 'Da seh ich ja wo es knallt' aber als dann einfach die WLAN Verbindung weg war wusste ich, dass es ja grundsätzlich noch funktioniert.

Ich habe nun eine neue Version (1.2.2) hochgeladen. Diese ist mit FritzOS 7.10 getestet. Soweit konnte ich keine Probleme feststellen.

Folgende Änderungen haben sich ergeben:

[list]
\* Korrektur von Datentypen und Schnittstellen
\* Schnittstelle für WANDSLIfConfig verfügbar (WANDSInterfaceConfigClient)
\* Schnittstelle für 5GHz WLAN Konfiguration verfügbar (WLANConfigurationClient2)
\* Schnittstelle für Gäste WLAN Konfiguration verfügbar (WLANConfigurationClient3)
[/list] 

Grundsätzlich sieht es eigentlich gut aus mit dem Code. Habe ihn mir jetzt aber nicht vollständig angesehen.

Allgemein kommst du wohl sowieso besser, wenn du async/await richtig implementierst statt mit den Awaitern manuell zu arbeiten.

Kann deinen Code allerdings momentan leider nicht ausprobieren, da mein Notebook in der Reparatur ist.

Es wird aber auch keine Exception geworfen?

Wie auch immer, versuch mal den Code umzustellen. Du arbeitest ja bestimmt auf einer Konsolenanwendung für den Anfang.

Probier mal:

        static async void Main(string[] args)
        {
            DeviceFactory factory = new DeviceFactory();
            FritzDevice device = await factory.CreateDeviceAsync(System.Net.IPAddress.Parse("10.0.0.138"));


            ConnectionSettings settings = new ConnectionSettings();
            settings.UserName = "username";
            settings.Password = "passwort";
            settings.BaseUrl = device.Location;

            WLANConfigurationClient client = await device.GetServiceClient<WLANConfigurationClient>(settings);
            await client.SetEnableAsync(false);
        }

Möglicherweise reicht es aber auch schon die BaseUrl wie ich es im obigen Code mache auf "device.Location" zu setzen.

Was heißt denn, es passiert nichts?
Läuft der Code im Debugger bis zum Clientaufruf durch?

Funktionieren denn andere Anfragem auf den WLanConfigClient?

Im einfachsten Fall würde ich das so machen, dass eine Datenbank aufgesetzt wird in der Anmeldung und Abmeldung gespeichert werden.

Zur Auswertung kann dann einfach zyklisch ein Select auf die Tabelle ausgeführt werden, auf alle Nutzer die aktuell Angemeldet sind.

Ich bin hier nun einen anderen Weg gegangen. Der für mich wesentlich einfacher umzusetzen war.

Statt die Tabellen zu Mergen, werden bei der Verarbeitung die Relations durchgegangen und die Spalten aus den ChildTabellen verarbeitet.

Falls dennoch jemand eine Idee für den beschriebenen Fall hat wäre ich dafür natürlich noch offen. Der jetzige Weg funktioniert allerdings auch ganz gut.

// EDIT: Noch ein paar Details mehr zu meiner Lösung.

Benötigt habe ich das oben beschriebene um verschiedenste Eingangsdaten (DataTable aus Datenbank, XmlDokument und Csv-Datenquellen) in eine konfigurierbare Csv-Struktur zu exportieren.
Der einfachhalt wegen bin ich dann den naiven Weg gegangen, dass ich mir gesagt habe, dass kann man alles in DataTables / DataSets einlesen. Eine Csv-Datei als Quelle ist ja schließlich auch nichts anderes als eine Tabelle.

Problem bereitete mir dann allerdings die Ermittlung der Xml-Knoten bei geschachtelten Xml-Dateien. Dazu habe ich mich dann erst einmal 3 Stunden darin verrannt die Tabellen zu mergen.

Am Ende bin ich dann doch den Weg gegangen, dass ich die DataRelations ausgewertet habe.

Aufbau der Datenermittlung war dann wie folgt:

foreach(DataRow row in sourceTable.Rows)
{
     for(int i = 0; i < this.SourceColumns.Count; i++)
     {

          if (i > 0)
             stringBuilder.Append(delimiter);

         string sourceColumn = this.SourceColumns[i];

         if(!sourceColumn.Contains("\\") && !sourceColumn.Contains("/")
         {
              stringBuilder.Append(rows[sourceColumn].ToString());
         }
         else
         {
              string[] tablePathParts = sourceColumn.Split(new char[] { '\\', '/' });
              DataRow[] relationalRows = row.GetChildRows($"{sourceTable.TableName}_{tablePathParts[0]}");
              if(relationalRows.Count > 1)
                 throw new ArgumentException($"Mapping not valid. Multiple entries for {sourceColumn} found.");
              else
                  stringBuilder.Append(relationalRows[0][tablePathParts[1]].ToString());
         }   
     }

     stringBuilder.AppendLine();      
}

Natürlich ist noch mehr Fehlerbehandlung enthalten. Aber im groben und ganzen löste das meine ganzen Probleme.

verwendetes Datenbanksystem: System.Data.DataSet

Hallo,

für einen aktuellen Anwendungsfall lese ich Xml-Dateien in ein DataSet ein. Da es hier durchaus auch verschachtelungen gibt und ich die Daten in einer Tabelle benötige wollte ich die Daten zusammen fügen.

Dazu werden durch das DataSet automatisch beim Einlesen Fremdschlüsselbeziehungen aufgebaut. Mein Gedanke war nun alle DataRelations der Tabellen durchzugehen und diese nach folgendem Prinzip zu mergen:

        private void MergeTables(DataTable dataTable)
        {
            foreach (DataRelation relation in dataTable.ChildRelations)
            {
                DataTable childTable = relation.ChildTable;
                this.MergeTables(childTable);

                dataTable.Merge(relation.ChildTable);
            }
            dataTable.AcceptChanges();
        }

Das funktioniert auch solang ich nicht zu weit verschachtele. Folgende Struktur funktioniert noch:

<?xml version="1.0" encoding="utf-16"?>
<Data>
   <Entry>
         <Type>
               <EventType>Import</EventType>
               <ImportType>-</ImportType>
         </Type>
         <Hint>DataHint</Hint>
         <Key>DataKey</Key>
   </Entry>
</Data>

Gehe ich aber bei Type noch eine Ebene tiefer funktioniert das ganze nicht mehr. Es wird eine unspezifizierte NullReference Exception geworfen.

Beispiel Xml:

<?xml version="1.0" encoding="utf-16"?>
<Data>
   <Entry>
         <Type>
               <EventType>Import</EventType>
               <ImportType>-</ImportType>
               <State>
                    <Valid>false</Valid>
                    <Error>some error</Error>
               </State>
         </Type>
         <Hint>DataHint</Hint>
         <Key>DataKey</Key>
   </Entry>
</Data>

Hat jemand eine Idee, wie ich das Problem lösen kann und die Daten in eine DataTable gemerged bekomme, auch bei höheren Verschachtelungstiefen?

Hier wiederspreche ich klar, dass die Formatzeichenfolge 2 stellig sein und einen gültigen Identifier besitzen muss. Zumindest was die Implementierung angeht. Denn "[[" ist sowohl bei ToString() als auch bei TryParseExact gültig.

Um noch mal ganz klar zu Erläutern was mein Ziel ist:

Über eine Konfigurationsoberfläche kann eine Formatzeichenfolge eingegeben werden. Meinetwegen "dd.MM.yyyy". Beim Speichern der Konfiguration soll geprüft werden ob "dd.MM.yyyy" eine gültige Formatzeichenfolge ist. Es liegt an der Stelle also kein Datum vor, dass irgendwie formatiert werden soll und keine Zeichenfolge die in ein DateTime umgewandelt werden soll.

Wenn es nur um die Prüfung ginge ob eine Zeichenfolge ein bestimmtes Datumsformat besitzt hätte ich ja keine Probleme. Das ist alles fein beschrieben. Aber ist ja eben nicht mein Problem.

Hallo Abt,

das ist mir ja alles klar. Ist ja aber auch nicht mein eigentliches Problem. Ich will ja nicht prüfen ob Datum X gütig ist. Das weiß ich an der Stelle.

Ich möchte prüfen ob die eingegebene Formatzeichenfolge gültig ist. - Und das ist sie eigentlich immer sobald sie mindestens 2 Stellig ist.

Insofern sieht die einzig sinnvolle Validierung so aus, dass geprüft wird ob bei DateTime.ToString(format) eine Exception geworfen wird oder nicht.

PPS: auch TryParseExact nimmt Formate an.

Japp, leider aber jede beliebige und erklärt sie für gültig. - Sofern es bei DateTime.ToString() nicht schon wegbricht.

DateTime.ToString("a") => Exception
DateTime.ToString("ab") => Ergebis: "ab"

Und "ab" kann ich leider auch wieder mit TryParseExact sauber parsen. Wird zwar je nach DateTimeStyles zu 01.01.0000 bzw. 13.06.2019 aber ist ja beides quatsch.

Ich glaube ich habe das Prinzip so langsam verstanden. - Solang die EIngangszeichenfolge dem Format entspricht ist es gültig. Unabhängig davon ob das Format Sinn macht oder nicht. - Eine Validierung wird damit sehr schwierig, da ja eben auch "Stunde: {0:hh}" ein durchaus gültiger String zur Formatierung ist.

Insofern hat sich das soweit erst einmal erledigt. Entweder wir definieren zuvor, was alles zulässig ist oder lassen die Validierung ganz weg.

Da fangen meine Probleme ja schon an. Es handelt sich beim Projekt um einen Converter von Eingangsdaten in das Csv-Format.

Nur für Datumswerte soll eine Formatierungszeichenfolge über die Oberfläche festgelegt werden können. - Die Validierung der Zeichenfolge gestaltet sich aber ziemlich schwierig.

Mein beschriebener Ablauf hat irgendwie merkwürdige auswüchse.

            DateTime dt = DateTime.MinValue;

            string dtAsString = dt.ToString("yyyyMMdd");

            if (!DateTime.TryParse(dtAsString, CultureInfo.InvariantCulture, DateTimeStyles.None, out dt))
                 Console.WriteLine("invalid format");
            else
                Console.WriteLine(dt.ToString());
          // Ergebnis => Invalid Format obwohl gültig

Liefert eine Exception => ungültiges Datumsformat. - Bei DateTime.TryParse kann leider kein Format mitgegeben werden.

Bei TryParseExact wirds aber erst richtig lustig. Vergebe ich dort nämlich ein ungültiges Format kommt das aktuelle Datum als Ergebnis raus und es gibt keinen Fehler / keine Exception.

            DateTime dt = DateTime.MinValue;

            string dtAsString = dt.ToString("ab");

            if (!DateTime.TryParseExact(dtAsString, "ab", CultureInfo.InvariantCulture, DateTimeStyles.None, out dt))
                 Console.WriteLine("invalid format");
            else
                Console.WriteLine(dt.ToString()); // 13.06.2019 ? wtf???

Hallo,

für eine Anwendung soll dem Benutzer erlaubt werden manuell das Datumsformat anzugeben. Nach Eingabe würden wir dies gern validieren ob es sich um eine gültige Formatzeichenfolge handelt.

Wie wäre hier die beste herangehensweise?

Meine Überlegung war: *Formatierung aktuelles Datum mit Formatzeichenfolge *DateTime.TryParseExact auf den erhaltenen String *Wenn true => gültige Formatzeichenfolge *Wenn false => ungültige Formatzeichenfolge

Ich bin mir nicht sicher, ob das so passt. Gibt es eine bessere / sauberere Lösung?

Hallo,

ja ich arbeite noch da dran, bin aber in den letzten Monaten leider nicht mehr dazu gekommen. Natürlich werden auch die bekannten Probleme behoben. Da ich das Projekt aber privat bearbeite kann ich dir hier keinerlei zeitliche Schiene geben.

Hallo,

ich hatte meinen Beitrag noch einmal editiert. Bezüglich dem Ein- / Ausblenden von Series kannst du ja die "Enabled"-Eigenschaft verwenden. Wenn eine Series nicht sichtbar sein soll, setzt du Enabled halt einfach auf false.

Hallo,

Bei mir wird immer nur die erste Series gezeichnet. Was mache ich hier falsch?

Hierfür wäre die Definition der Series relevant und wie denn das Ergebnis aussieht.

Und warum muss das zeichnen in einer der whileschleife vom reader machen....?

Möglicherweise kommst du besser, wenn du das Ergebnis in ein DataTable einliest. Dies kannst du dann an die Chart binden. Aktuell fügst du ja quasi jeden Punkt einzeln hinzu. Im übrigen musst du keine Schleife dafür erstellen. Du kannst direkt ohne Umwege deine Series mit BindXY füllen ganz ohne Schleife.

Probier mal folgendes:

            chart1.DataSource = myReader;

            chart1.Series[0].Enabled = true;
            chart1.Series[0].XValueMember = "zeitstempel";
            chart1.Series[0].YValueMembers = "var1";
            chart1.Series[0].ChartType = SeriesChartType.Line;
            chart1.Series[0].YValueType = ChartValueType.Auto;
            chart1.Series[0].XValueType = ChartValueType.DateTime;
            chart1.Series[0].Name = "var1";
            chart1.Series[0].Color = Color.Aqua;

            chart1.Series[1].Enabled = true;
            chart1.Series[1].XValueMember = "zeitstempel";
            chart1.Series[1].YValueMembers = "var2";
            chart1.Series[1].ChartType = SeriesChartType.Line;
            chart1.Series[1].YValueType = ChartValueType.Auto;
            chart1.Series[1].XValueType = ChartValueType.DateTime;
            chart1.Series[1].Name = "var2";
            chart1.Series[1].Color = Color.Red;

            chart1.DataBind();

aber bei "public EmployeeRepository (IDbConnection connection) : base(connection)" ist Schluss. Vermute mit ":base(Connection)" implementierst du etwas wo die Verbindungsdaten geregelt sind, liege ich damit richtig?

EmployeeRepository erbt von der Basisklasse SqlRepository<EmployeeEntity>. Der Aufruf am Ende des Konstruktors bewirkt, dass der Konstruktor der Basisklasse aufgerufen wird.

Was genau hast du denn vor? Ich verstehe dein Gesamtproblem nicht.

Was ist denn das für ein verquerer Anwendungsaufbau wenn zur Laufzeit irgendwelche DLL's generiert werden und nach Verwendung wieder verschwinden?

Hallo aloneboy,

arbeite mit DataBinding. Bei Wertänderung in Form1 kannst du dann auf PropertyChanged horchen und in Form2 auf den geänderten Wert reagieren.

Beispiele wie man das korrekt und sinnvoll anwendet wirst du hier im Forum und auch im Weltennetz zu hauf finden.

Dann solltest du mit dem Debugger prüfen, warum er aus der Schleife aussteigt obwohl noch zu lesende Daten vorhanden sind.

Entweder es sind alle Tabellen gelesen und somit keine Daten mehr zum Lesen vorhanden oder aber du schluckst irgendwo eine Exception.

Ja. Windows legt die Dateiendung an, wenn du über das Kontextmenü eine Textdatei erstellst. Wenn du die umbenennst musst du doch aber die Dateiendung nicht selbst noch einmal setzen.

Du verursachst damit das Problem ja selbst und nicht Windows.

Na schon über Erfahrungswerte. Bei z.B: einem Job der neue Daten alle 5 Minuten aus einer Tabelle in eine andere schaufeln soll, weiß man ja wie lang das ungefähr dauern dürfte. Man kennt ja das Datenaufkommen und kann sich damit herleiten wie lange es dauert.

Wenn z.B. 100 Datensätze pro 5 Minuten kommen sind das entsprechend 1 Select und ggf. 100 Inserts/Updates. Nehmen wir an das Select dauert 1 Sekunde und je Insert noch mal 1 Sekunde kommen wir auf 101 Sekunden (Fiktive Beispielwerte). - Wenn der Job nun meinetwegen 10 Minuten läuft wissen wir ja das irgendwo etwas faul ist.

// EDIT: Eine alternative Lösung wäre über die Historie die durchschnittliche Laufzeit zu ermitteln und anhand dieser den Grenzwert zu definieren.

Tschuldigung. Nun bin ich doch auf die Lösung gestoßen. Für alle die es Zukünftig auch mal brauchen:

Es muss die Projektdatei angepasst werden.
Im Knoten Project\PropertyGroup liegt der Xml-Knoten "Deterministic". Ab Visual Studio 2017 scheint der beim anlegen eines neuen Projektes mit dem Wert "True" erstellt zu werden. Der Wert muss hier auf "False" eingestellt werden und die Versionierung funktioniert wieder.

Damit erfahre ich ja auch nur, dass der Job gerade läuft. Aber nicht, ob er längst fertig sein sollte und erneut gestartet worden sein sollte.

Möglicherweise mache ich es mir auch zu kompliziert und es wäre einfacher zusätzlich für den jeweiligen Job in der Konfiguration zu hinterlegen wie lang er maximal laufen sollte.

Verwendete Entwicklungsumgebung: Visual Studio Professional 2017

Hallo,

ich habe ein bestehendes Projekt um ein neues Modul erweitert. In der AssemblyInfo.cs habe ich die Versionsnummer mit Platzhalter festgelegt:

[assembly: AssemblyVersion("1.0.*")]

Beim Kompilieren erhalte ich allerdings je den Compilerfehler CS8357:

Fehlermeldung:
Die angegebene Versionszeichenfolge enthält Platzhalter, die nicht mit dem Konzept des Determinismus kompatibel sind. Entfernen Sie entweder die Platzhalter aus der Versionszeichenfolge, oder deaktivieren Sie den Determinismus für diese Kompilierung.

Meine Frage ist jetzt, wo kann ich den Determinismus abschalten? - Ich finde im Visual Studio irgendwie keine Einstellung dafür.

Hallo,

aktuell erstelle ich eine Anwendung zur aktiven Überwachung von MSSQL Jobs. Die Erkennung des letzten Ausführungsstatus eines Jobs ist einfach. Wie erkenne ich jedoch ob ein Job zu lange läuft?

Die Abfrage der Job-Informationen wird mit der System-Prozedur "sp_Help_job" unter Angabe des Job-Namen ausgeführt.

Leider werden erst nach Beendigung eines Jobs der Zeitpunkt der letzten und nächsten Ausführung gesetzt. Habe ich nun einen Job der minütlich laufen soll und der Job läuft aber allein schon 5 Minuten möchte ich das erkennen. Problem ist aber, dass ich zwar erkennen kann ob der Job läuft (execution_status) aber nicht ob er zu lang läuft, da ich ja nicht erkenne wann er gestartet wurde so lang er läuft.

Hat jemand eine Idee, wie ich da am besten herangehen könnte?

Naja, für mich wirkt es aber schon sehr merkwürdig, dass du mit der externen IP zugreifen kannst, die interne aber die Dienste verweigert.

Genaueres müsste man dann im Detail prüfen. - Ich bin leider noch nicht dazu gekommen die Anwendung anzupassen.

Erstens nutze bitte die Code Tags.

Ansonsten sieht es mir so aus als wäre Zustandskenngroessen eine Klasse mit statischen Membern. Gerade für deinen Fall ist das eine sehe schlechte Wahl.

Wieso legst du in deinem steuerelement nicht einfach Properties für die Zustände an? Bei Änderung eines Zustands im Form, setzt du dann einfach den entsprechenden wert.

Das klingt aber stark nach fehlerhafter Konfiguration der Box. Denn ich hätte jetzt eher Probleme beim Zugriff von außen erwartet.

Wie dem auch sei, sofern ich morgen die Zeit finde, werde ich mal die aktuelle API Version anbinden. - Dannach können wir weiter sehen ob es weiterhin Probleme gibt.

Moment, remote funktioniert es? Und im Lan unter der HTTPS Url nicht?

Da ich nun seit Freitag eine neue FBox habe muss ich sagen ich kann das Problem noch immer nicht nachvollziehen. - Denn auch mit der neuen Box (7530 statt 7330) funktioniert das ganze ohne Probleme.

Hatte zuletzt einen mehr oder weniger funktionierenden Weg mit den Charts gefunden von dem ich mich aber aufgrund der Komplexheit dann doch entfernt habe.

Selbst zeichnen ist hier leider deutlich weniger aufwendig.

Hallo witte,

eigentlich hatte ich gehofft, dass es mit dem Chart aus dem Framework (Windows Forms) funktioniert ohne selbst zu zeichnen.

Hallo,

ich stehe irgendwie gerade auf dem Schlauch. Für ein aktuelles Projekt muss ich ein Chart zeichnen, das verschiedene Bereiche ausgibt ähnlich einen "Doughnut"-Chart. Ich habe aber keine Ahnung wie ich die Einstellungen definieren muss.

Das Original-Chart ist vom Kunden in Excel erstellt wurden und im Anhang zu finden. Soweit ich das sehe müsste ich doch die Chart-Eigenschaften irgendwie auf das Windows Forms Chart übernehmen können. Hat jemand einen Tipp für mich?

Im aktuellen Ausbaustand ist das leider nicht möglich.

// EDIT:
Da ich aktuell an meinem "FritzBox Manager" weiterarbeite werde ich bei Gelegenheit die VOIP Schnittstelle mit implementieren und eine neue Version der API bereitstellen in der auch die letzten Bugfixes enhalten sind.

Im übrigen: Falls jemand einen Weg findet, das komplette LOG der Box auszulesen per TR064 wäre ich sehr dankbar. - Scheinbar geht das nur für die Internetverbindung selbst, Telefonie und WLAN Logs habe ich bisher nicht lesen können.

All dein Code in Window_Loaded zu packen ist etwa so wie: Beim Hausbau die Heizungsinstallation im Vorgarten installieren zu lassen - Kann man machen, ist halt nicht wirklich gut

Der Vergleich hinkt. Eher müssten Vorgarten und Wasseranschlüsse im Wohnzimmer verbaut sein.

Zusätzlich sei noch gesagt, dass durch die "eigene DLL" die Austauschbarkeit verbessert wird. Man kann nun die erste DLL komplett gegen eine andere ersetzen, passt in der zweiten die Codestellen an und für den Verwender der eigenen DLL ändert sich nichts.

Lad dir mal die im Anhang enthaltene Version des NetzwerkMonitor und prüf mal ob es mit dieser funktioniert. => Achtung: Es gibt da nun einen neuen Schlüssel der festlegt ob die Informationen über die WANIPConnection abzurufen sind. Daher können maximaler Up- und Downstream nicht ermittelt werden.

Musstest du denn noch sachen Ändern, um den Reboot-Task auszuführen oder klappte das mit dem aktuellen Code? Das wäre insofern interessant als das ich etwaiige Änderungen für die nächste Version ja übernehmen könnte.

Da ich nun wiedererwarten die letzten Monate nicht dazu gekommen bin, starte ich jetzt mit der Weiterarbeit am Projekt. - Den Development Branch lasse ich stehen, der wird aber derzeit keine Anwendung finden.

Weitergearbeitet wird mit dem Stand des Master Branches. Das aus dem Grund, dass damit auch die extremen Breaking Changes aus dem Development Branch entfallen.

@Abt: Das bedeuted jetzt natürlich, dass du auch auf den aktuellen Stand Änderungsvorschläge machen kannst.

D.h. ihr pflegt Kunden(stamm)daten in einer Access-Datenbank?

So wie ich ihn verstanden habe in einer MSSQL-Datenbank. Als GUI kommt Access mit verlinkten MSSQL-Tabellen zum Einsatz. D.h. Access ist quasi nur die GUI für die MSSQL-Tabellen.

Nichts desto trotz stimme ich natürlich zu, dass es bessere Lösungen zum Anzeigen und Bearbeiten der Daten gibt. Stammdatenpflege gehört aus meiner Sicht entweder in ein Intranet-Portal oder eine Anwendung, die nicht direkt auf Tabellen-Ebene rumoperieren sondern bestenfalls noch einen Webservice zwischen geschaltet haben.

Möglicherweise ist ja SQLDataEdit etwas für dich / deinen Kunden.

// EDIT:

Alternativ, was hält dich davon ab selbst ein kleines Tool in der Richtung zu entwickeln für den Kunden? Soweit ich das sehe sind die Anforderungen ja nicht all zu hoch.

• Abfrage aller Tabellen
  -> Benutzer wählt eine Tabelle aus
  -> Tabelle wird in einem DataGrid angezeigt
  => Benutzer kann Daten der Tabelle ändern und Speichern

Hallo,

lese die CSV Datei in eine intelligent gewählte Datenstruktur (je nach vollständigem Aufbau und ggf. Änderungen eine Klasse oder direkt ein DataTable) ein. Dafür suchst du nach "C# read CSV File". Anschließend durchsuchst du die Daten.

Danach löschst du eben alle Einträge die weg sollen und schreibst die CSV-Datei zurück auf das Filesystem.

Wie meinen? Du erstellst halt unterschiedliche Nutzer mit unterschiedlichen Rechteebenen. Je Nutzer lässt du dann einmal das Programm laufen. - Natürlich mit gleichen Voraussetzungen, d.h. im Hintergrund laufen auch die gleichen Prozesse ab.

Hallo,

für eine Anwendung suche ich die Möglichkeit alle auf einem PC / Server im IIS gehosteten Webservices zu ermitteln (im Optimalfall Url und Dateisystem-Pfad). Die Ermittlung sollte dabei nicht nur lokal sondern auch remote möglich sein. Weitere Voraussetzung ist, dass dies ab Windows 7 funktionieren muss.

Gibt es da etwas in der Richtung, dass dies erlaubt / ermöglicht?

Zuallererst bietet die Variante mit den Interfaces den großen Vorteil, dass du Regeln flexibler hinzufügen und entfernen kannst. Bei Events musst du immer wieder an der Game-Klasse rumwerkeln.

Um auf dem aktuellsten Stand zu sein, sollte der TE dennoch die Community-Edition nutzen.

Zusätzlich zum gesagten, kannst du es ja eventuell auch anders angehen.

Konkreten Tipp habe ich nicht aber einen Methodennamen / Stichwort: ContinueWith

Eine weitere Möglichkeit wären noch Sub-Selects ala

SELECT * 
FROM (
    SELECT
        CASE WHEN x = y THEN 1 ELSE 0 END AS Wert1,
        CASE WHEN y = z THEN 1 ELSE 0 END AS Wert2
    FROM Tabelle
) WHERE Wert1 = 0

Ist es tatsächlich eine "API" also quasi ein Webservice oder ähnliches, oder ist es eine kleine Seite mit Ausgaben?

Im ersteren Fall kann man das sicher einbinden (mit ein wenig PHP-Entwicklung).

Dann hast du nicht korrekt mit dem Debugger gearbeitet. - Normalerweise springst du für jeden Schleifenumlauf erneut in den Rumpf. - Nach deiner Beschreibung dürfte das nur einmal passieren und sollte ein starkes Indiz liefern.