ILIst ist ein bisschen Kanone auf den Spatzen, der vorgeschlagene Indexer kommt deiner Anforderung am nächsten:
class Test
{
private string[] _array = new string[] { "Element 1", "Element 2", "Element 3" };
public string this[int index]
{
get => _array[index];
set
{
onItemChanged(index);
_array[index] = value;
}
}
private void onItemChanged(int index) => Console.WriteLine(index); // todo
}
class Program
{
static void Main(string[] args)
{
Test test = new Test();
test[1] = "Ersetze dieses Element";
}
}
Natürlich vor dem Zugriff auf's Array immer schön prüfen, ob es das Element überhaupt gibt.
Nachtrag:
Ich bin seit September nach fast 20 Jahren Visual Studio auf Rider umgestiegen. Für so ein Gewohnheitstier, wie ich es bin, ein riesiger Schritt. Jetzt, ein Vierteljahr später, sind die schlimmsten Entwöhnungserscheinungen erledigt und ich muss sagen, ich bin ziemlich happy mit der IDE. Ich kann aber nicht sagen, wie gut oder schlecht sich Windows.Forms oder WPF damit entwickeln lassen, ist nicht mein Anwendungsfall. Wer die Möglichkeit hat, sollte Rider ruhig mal eine Chance geben.
LaTino
(der nächste XPS kann dann eine Developer Edition mit Linux werden :evil
gerade dreimal versucht, einen Text zu posten, der einen Emoji enthielt (eingefügt über Win+.). Dreimal Fehler - nur dieses eine Zeichen entfernt, und es ging.
Seit die Möglichkeit existiert, nutze ich anstelle der Kreditkarte Android Pay, verknüpft mit Paypal. So landen die Informationen zu Kreditkarte oder Bankkonto nicht mehr beim Zahlungsempfänger, und es ist nur noch eine Frage, ob man eben Paypal traut oder nicht. Kann jeder für sich entscheiden, und ich verstehe auch jeden, der's nicht tut.
Ganz ohne Kreditkarte würde mir mein Alltag inzwischen sehr schwer fallen, ich benutze die eigentlich seit 2006/07 als bevorzugtes Zahlungsmittel. Auch wenn das in Deutschland immer noch nicht überall geht (im Jahr 2020, in einer Pandemie, kriegt man immer noch "wir können nur EC-Karte", "nein, kontaktlos geht leider nicht" zu hören...).
.NET Core / .Net 5
Editor: Visual Studio Code (keine Lizenzgebühren, frei verfügbar, alle gängigen Betriebssysteme)
Für das, was du deinen Schülern beibringen willst, brauchst du keine IDE. Ein Editor reicht, dann liegt der Fokus auch auf dem Programmieren und nicht auf der IDE (mal abgesehen davon, dass ich dir die Kompatibilitätsprobleme von Projektmappen zwschen 2017 und 2019 nicht abkaufe. Die sind identisch.) Ich erinnere mich dunkel, dass wir in der Java-Vorlesung erstmal zwei Stunden mit EInführung in Eclipse verbracht haben. Unnötig, umständlich, langweilig.
Die Hinweise hier gehen alle in die Richtung, dass die Nutzung der moderneren, schlankeren, leichter zugänglichen Variante von .NET empfohlen wird. Und das zu Recht. Offen gesagt, lesen sich deine Antworten dagegen eher so, dass du dir einen ganz anderen Aufwand sparen möchtest. Nämlich den, etwas neues zu lernen.
Das hängt stark davon ab, was du mit Resharper am häufigsten tust. Den von dir erwähnten Zweck zB nutze ich (private Lizenz seit 2014) überhaupt nicht, bzw. er ist mir unwichtig.
Für die von mir am häufigsten genutzten Funktionen gibt es schlicht keine Alternative, von Rider vielleicht abgesehen.
Und die gut 100 Euro im Jahr ist das Stück Software auf jeden Fall wert. Das sind sehr grosszügig gerechnet 5 gesparte Stunden Arbeitszeit pro Jahr, ab denen sich das lohnt (realistisch deutlich weniger).
Update der Package Microsoft.EntityFrameworkCore von 3.1.1 auf 3.1.5 hat das Problem beseitigt. Ich habe in den Readmes keinerlei Hinweis auf eine Änderung diesbezüglich gefunden. Nicht die erste Änderung in net core 3.1, die unsere Build-Pipeline zerschießt. Ärgerlich, unnötig.
So, ich habe noch einmal etwas gebuddelt. Das Problem haben wir uns mit einer Abhängigkeit auf Microsoft.EntityFrameworkCore eingetreten. Das NuGet-Package listet die drei Abhängigkeiten auch auf - die Merkwürdigkeit ist also, dass die Bibliotheken unter Windows fehlen, und nicht, dass sie unter Linux auftauchen.
Interessanterweise:
dotnet new console -o Example
cd Example
dotnet add package Microsoft.EntityFrameworkCore
dotnet publish ./Example.csproj -o ../publish -c Release
ls ../publish
..führt dazu, dass die Bibliotheken auch unter Windows im Ausgabeverzeichnis liegen.
Es liegt also vermutlich am Projekt, wobei ihr mir nicht wirklich helfen könnt. Ich werde die Abhängigkeiten mal Stück für Stück entfernen / wieder einfügen und schauen, ob das einen Effekt hat. Sollte ich über die Lösung stolpern, melde ich mich wieder.
Der Punkt, den ich nicht nachvollziehen kann, ist dieser hier:
Zitat von gfoidl
Durch die Angabe der Ziel-Runtime --runtime win-x64 wird entweder "cross compiled" od. nicht. Daher kann es -- auch beeinflusst von den NuGet-Referenzen -- zu Unterschieden der Build-Ausgabe kommen.
Mein zugegeben unvollständiges Verständnis des Vorgangs ist, dass eben gegen die entsprechenden Bibliotheken der Zielplattform kompiliert wird. Die drei unter Linux eingebundenen Bibliotheken werden auch nicht genutzt - sonst würde das unter Windows erzeugte Ergebnis, dass diese Bibliotheken nicht hat, ja gar nicht laufen.
Ich hätte das als reine Unschönheit abgetan, allerdings verursachen die verschiedenen Ergebnisse einen Schluckauf in unserer Gitlab-Pipeline, der langsam echt störend wird.
ich bin heute über eine Merkwürdigkeit gestolpert, für die ich keine Erklärung habe. Wir haben GitLab im Einsatz, einige Runner unter Linux, einige unter Windows. Mir ist heute aufgefallen, dass die Ergebnisse des "dotnet publish" Befehls für dieselbe Target Runtime unterschiedliche Ergebnisse erzeugen.
Das Ergebnis, das die Linux-Runner erzeugen, enthält drei Dateien, die die Windows-Runner nicht dazupacken:
- System.Collections.Immutable.dll
- System.ComponentModel.Annotations.dll
- System.Diagnostics.DiagnosticSource.dll
Ich war bisher davon ausgegangen, dass ich mich darauf verlassen kann, dass ein und derselbe Befehl in ein und derselben SDK-Version zu ein und demselben Ergebnis führt. Das jetzt verunsichert mich doch ziemlich.
@LaTino
Das klingt wirklich nach harter Belastung. Bist du Alleinerziehend oder kann dich deine Frau da nicht unterstützen?
Meine Frau ist "systemrelevant" (im Gegensatz zu all den anderen Berufen, auf die man offensichtlich verzichten kann ). Und natürlich unterstützt sie, wo sie kann, aber wir sehen uns quasi nur zwischen 17 und 20 Uhr und sehr früh morgens . Ich glaube auch nicht, dass wir da eine Ausnahme sind, das dürfte vielen so gehen. Und die Alleinerziehenden mit 2 oder mehr Kindern...in deren Haut möchte ich nicht stecken.
Hoffe doch, dass du durch hälst bis alles mehr oder weniger vorüber ist. ;-)
Das geht schon, man muss mehr drauf achten, sich nicht zu verbrennen. Viel schlimmer ist für Kinder in dem Alter, wochenlang (meine: seit 7 Wochen) kein anderes Kind, geschweige denn ihre Freunde, zu sehen. Der Aspekt kommt in der öffentlichen Diskussion kaum vor, es geht fast nur darum, wann die Eltern denn nun wieder arbeiten können. Ist das erste mal, dass ich deutlich merke, wie wenig Kinder in diesem Land zählen und wie tief das im gesellschaftlichen Mindset verankert ist. Gruselig.
habe ich weder privat noch das Unternehmen, für das ich arbeite, Einbußen zu verzeichnen. Liegt sehr wahrscheinlich an der Branche, die eine der krisenfesteren ist.
LaTino
ich stehe fünf auf, arbeite bis halb acht, betreue dann die 3jährige (und nein, da kann man nicht nebenbei arbeiten), arbeite, falls der Mittagsschlaf klappt, zwischen 12 und 14 Uhr noch etwas, und dann ab 20 Uhr bis mindestens Mitternacht. Es ist etwas zermürbend auf Dauer und bestimmt auch nicht gesund, aber dafür habe ich das Privileg, keine anderen Einbußen zu haben.
(Plus bisschen Speicher gegebenenfalls.) B1s ist auch das, mit dem ich nahezu immer starte, wenn ich auf die Schnelle was Preiswertes suche. Kann ich empfehlen.
@MrSparkle, letzte Reaktion hier von mir, entschuldige bitte :o)
Zitat von herbivore
Die Politik (nachträglich) zu kritisieren, ist leicht. Es besser (gemacht) zu machen, schon sehr viel schwieriger.
Ich meine die Situation im Gesundheitswesen im Allgemeinen und die schlechte Vorbereitung und langsame, dann aber aktionistische Reaktion.
Und nein, "mach's besser" ist keine angemessene Reaktion, sondern unlauter argumentiert. So stehlen sich nur Leute aus der Verantwortung, die sie freiwillig übernommen haben. Niemand hat irgendwen gezwungen, Politik zu machen. Selbstverständlich wird auch nicht erst kritisiert, seit die Krise da ist, sondern schon sehr lange vorher. Es hat nur keinen interessiert.
Im übrigen muss ich auch keinen Film drehen oder ein Buch schreiben können, um beurteilen zu können, ob ein Buch oder Film handwerklich schlecht sind. Dieses Argument lasse ich nicht gelten. (Meine Frau arbeitet im Gesundheitswesen, ich kriege hier seit Jahren mit, wie nur noch auf Verschleiß gefahren wird. Soll mir keiner erzählen, damit hätte keiner rechnen können.)
So, das soll's gewesen sein. Wie gesagt, wer mitgemacht hat: danke für den Enthusiasmus und den Versuch, ich drücke die Daumen, dass es nicht umsonst war.
Mich macht die Aktion eher wütend. Placebo-Aktionismus, der ein bisschen Futter für die Presse liefert, und die Verantwortung für die Lösung politikverschuldeter Probleme wird elegant an die Nerds weitergereicht, die sich dafür instrumentalisieren lassen.
Nichts gegen die Leute, die mitgemacht haben. Ich hoffe, sie hatten Spass, haben was gelernt und interessante Leute kennengelernt. Ich fürchte aber, die praktischen Auswirkungen werden sich auf ein paar wohlwollend-herablassende Presseartikel beschränken.
Ich lasse mich sehr gern eines Besseren belehren, allein, mir fehlt der Glaube.
Wäre das Testen von Code ein gelöstes Problem, gäbe es weder Witze darüber, noch fehlerhafte Software.
Ein Testcoverage-Tool, das dir anzeigt, welche Zeilen bereits im Rahmen eines Tests durchlaufen wurden, kann helfen, ungeprüfte Fälle zu finden. Ich benutze dafür dotcover (Resharper). So ein Tool prüft natürlich nicht, ob das Test selber die richtigen Überprüfungen macht. Ist aber dennoch ein sehr guter Helfer dabei, Testfälle zu entdecken, die man übersehen hatte.
Ich finde auch die Aussage irritierend, Unit Tests würden hier nichts nutzen, weil man ja etwas übersehen würde.
"Wir können Methode xy nicht benutzen, weil wir sie falsch/unvollständig nutzen würden."
Äh, was?
Inputvalidierungen lassen sich sehr gut per Komponententest prüfen. Voraussetzung wäre natürlich, dass man weiss, was ein valider Input ist. Andererseits macht die Angabe "validiere xyz", ohne festzulegen, was ein valider Wert ist, noch weniger Sinn als die Aussage oben.
LaTino
(Disclaimer: Wenn die Teststrategie NUR aus Komponententests besteht, ist selbstredend auch was verkehrt. Mich hatte nur die Aussage irritiert.)
Der Urheber ist nicht mehr bei meinem AG beschäftigt. Seinem Code nach zu urteilen, hat er aber sehr oft "nachts gearbeitet". Der ist jetzt übrigens (wieder) in der Lehre beschäftigt - lehrt OOP. Manche Geschichten kann man sich nicht ausdenken.
public static Nullable<T> GetEnum<T>(int? EnumInt) where T : struct {
foreach (var item in Enum.GetValues(typeof(T))) {
if ((int)item == EnumInt) {
return (T?)item;
}
}
return null;
}
Okay, soweit, so...ungewöhnlich, aber gut, wenn einer das lieber selber macht als die .NET-Methoden zu nehmen, des Menschen Wille ist sein Himmelreich.
Aber dann. Die Methode wird zweimal verwendet. Beide Male so:
Die Punchline? data.Property ist vom Typ MyEnumType.
Wir nehmen das Enum, casten nach int, werfen das int in eine Methode, die einen Nullable von dem Enum baut, von dem wir kommen, und casten dieses Nullable dann hart in den Ursprungstyp.
Ich für meinen Teil sehe keinen Grund, das nicht stehen zu lassen. Serialisierung für Vergleiche zu nutzen, liegt ja relativ nahe, der Gedankengang ist meistens etwa so:
- Vergleich von Hand zu schreiben nervt
- Vergleich mit Reflection über die öffentlichen Member funktioniert
- feststellen, dass beim Serialisieren auch mit Reflection die öffentlichen Member ausgewertet werden
--> direkt Zurückgreifen auf Serialisierung
Die Idee haben wahrscheinlich die meisten Entwickler mal irgendwann ;). Und im Normalfall geht das auch, der Teufel steckt nur leider im Detail. Ich finde es nicht verkehrt, den Teufel hier mal zu skizzieren und das auch im Forum zu lassen. Muss aber ein Admin entscheiden (eventuell verschieben?).
Falls nicht klar ist, was ich meine, ein Beispiel. Es gibt, ohne zu übertreiben, Dutzende Möglichkeiten, Vergleiche über Serialisierung kaputtzumachen. Nicht empfehlenswert. Gäbe es eine generische Möglichkeit, komplexe Klassen zu vergleichen, bräuchte man IEquatable/IComparable nicht.
public class TestEquals
{
[Fact]
public void TestEquals()
{
Example expected = new Example {ExampleString = "example"};
Example actual = new InheritedExample { ExampleString = "example" };
Assert.True(expected.Equals(actual)); // Fehler.
Assert.True(actual.Equals(expected)); // Fehler.
}
}
public class InheritedExample : Example { [XmlIgnore] public override string ExampleString { get; set; } }
[XmlInclude(typeof(InheritedExample))]
public class Example
{
public virtual string ExampleString { get; set; }
public bool Equals<T>(T value)
{
/* ...snippet hier. */
}
}
Da der Vergleich auf Serialisierung basiert, wird er unter bestimmten Voraussetzungen fälschlich true liefern, obwohl die Objekte verschieden sind, oder umgekehrt.
Dort kannst du auch ggf die Daten und Anleitungen für dein Webhosting finden. Ionos' Kundenservice ist (zumindest meiner Erfahrung nach) überraschend gut, die werden dir eher weiter helfen können als ein C#-Forum. Dein Problem liegt ja nicht direkt an C# ;).