du kennst ja das Interval aus der DB. Dann reicht es doch aus zu prüfen, ob der Eingang der Nachricht (DateTime.UtcNow) in diesem Interval liegt.
Ich schreibe explizit vom Datum in UTC, da du es auch in UTC in der DB speichern solltest, um Probleme bei der Zeitumstellung zu vermeiden.
Den aktuellen Wochentag erhälst du ebenfalls über die DateTime-Klasse.
Also manchmal sollte man bestimmte Warnung auch ignorieren. Obige gehört für mich dazu.
Der modifizierte Code würde meiner Meinung nach die Lesbarkeit/Verständlichkeit des Codes verschlechtern. Siehe dazu auch als Beispiel auch CA2202, how to solve this case.
Zitat
It's really bad to create ugly code just to comply with a warning that should be suppressed.
ich kann leider auch nicht sagen was da schief läuft, aber folgendes funktioniert einwandfrei (egal ob Debug oder nicht): (Compress/Uncompress Methoden entnommen von String compression using GZipStream)
[TestClass]
public class UnitTest1
{
[TestMethod]
public void Test_Success()
{
var s = Compress("Hello World");
Assert.AreEqual("Hello World", Decompress(s));
}
public static byte[] Compress(string text)
{
using (var ms = new MemoryStream())
{
using (var zip = new GZipStream(ms, CompressionMode.Compress))
using (var writer = new StreamWriter(zip))
writer.Write(text);
return ms.ToArray();
}
}
public static string Decompress(byte[] compressed)
{
using (var ms = new MemoryStream(compressed))
using (var zip = new GZipStream(ms, CompressionMode.Decompress))
using (var sr = new StreamReader(zip))
{
return sr.ReadToEnd();
}
}
}
reicht die internal Sichtbarkeit für dich evtl. aus?
Dann könntest du die setter internal machen und sie sind somit nur von deiner Logik Klasse setzbar, da sich diese in der gleichen Assembly befindet (ich nehme an, die GUI ist in einer separaten Assembly).
du kannst in einer Class library schon ein ResourceDictionary erzeugen.
Ich hab dir mal ein beispielprojekt angefügt, das ein ResourceDictionary aus einer Class library einbindet.
var filename = @"F:\tmp\test.zip";
SevenZip.SevenZipCompressor.SetLibraryPath(@"C:\Program Files\7-Zip\7z.dll");
var extractor = new SevenZipExtractor(filename);
extractor.ExtractArchive(@"F:\tmp");
extractor.Dispose();
Ich habe 7-zip in der 64-bit version installiert und wenn ich in VS als Target auch 64-bit wähle, dann passt alles. Wenn ich allerdings AnyCpu wähle, bekomme ich die gleiche Meldung wie du.
Sprich: Stell sicher, dass deine platformen zusammen passen.
Wenn ich das richtig verstanden habe, dann musst du in SetLibraryPath den Pfad zu der 7-zip dll angeben. Die SevenZipSharp dll musst du ja ohnehin schon referenziert haben, sonst würdest du die Typen (z.B. SevenZipExtractor) ja gar nicht kennen.
das klingt für mich nach einem Pfad-Problem. Bist du dir sicher, dass du den Pfad korrekt angibst? Füg doch vor dem Process.Start() einfach mal ein File.Exists() ein, und schau ob der von dir verwendete Pfad als Datei überhaupt existiert. Dann weisst du wenigstens schonmal ob es daran liegt.
ok, jetzt verstehe ich deine gewünschte Sortierung (hoffentlich) ;)
Ohne voriges tagging könntest du auch die zwei Teil-Listen sortieren (zahlen ohne false und zahlen mit false) und später wieder mergen. Ist zwar nicht elegant, aber du ersparst dir das tagging.
hier kommt zum Tragen, dass für Wertetype wie int, double etc. keine Varianz unterstützt wird, sondern nur für Referenztypen. Lies dir am Besten mal die FAQ zu Co- und Contravariance durch: Covariance and Contravariance FAQ
so wie ich das sehe sind ja in TeamHandler.ActiveItems schon alle Einträge aus der DB enthalten. Das ist ja das eigentliche Problem und nicht die zwei for-schleifen zum filtern. Du solltest bei der DB-Selektion der Einträge schon darauf achten, dass du nur die relevanten Einträge holst.
wie du weiter vorgehst ist letztendlich deine Entscheidung, die dir hier niemand abnehmen kann.
Es kommt ja, wie herbivore gesagt hat, darauf an ob von Anfang an eine kommerzielle Absicht bestand. Wenn es z. B. im Rahmen eines Studienprojektes entstanden ist und du es jetzt mit Express weiterverfolgst, sehe ich kein Problem.
Wenn es aber von Anfang an nicht für einen akademischen Rahmen gedacht war, dann hättest du ja zum jetztigen Zeitpunkt eh schon gegen die Richtlinien von Microsoft verstossen. Ob es da ratsam ist Microsoft zu kontaktieren ist fraglich.
MuPdf ist ja in C geschrieben. Meine Komponente bringt quasi einen Teil der Funktionalitäten von MuPdf nach .NET.
Meine Komponente ist rein für die Darstellung von PDF Dateien da. MuPdf bietet darüber hinaus noch weitere Features, z. B. Textsuche o. ä.
MoonPdf ist ein momentanes Projekt von mir. Es umfasst ein PDF Viewer Control (MoonPdfLib) und einen beispielhaften Einsatz dieses Controls in Form eines PDF Viewers (MoonPdf).
Beide Komponenten sind WPF-basiert.
MoonPdfLib setzt auf der Rendering Engine von MuPdf auf und hat daher auch keine weiteren Abhängigkeiten wie z.B. zum Adobe Reader.
Am Besten den MoonPdf PDF Viewer herunterladen um direkt PDFs zu öffnen.
Das Projekt ist noch relativ am Anfang daher bin ich für Feedback aller Art dankbar.
Lasse ich die Anwendung aber über die Mess-Software starten, dann stürzt meine Anwendung ab.
Was ist denn die Fehlermeldung die beim Absturz deiner Anwendung auftritt? Wenn in der von dir ermittelten Zeile eine Exception geworfen wird, dann setzt doch ein try-block darum, und lass dir im Catch-Block die Exception ausgeben.
Dann weisst du warum die Anwendung abschmiert.