SSL wird Global in der Klasse gesetzt. Kann es sein, das diese Globale Einstellung nach eienr gewissen Zeit verloren geht?
Nein, kann nicht sein.
Aber die WebRequest-Klasse ist seit >10 Jahren veraltet; verwende den HttpClient. Beachte auch die Hinweise in der Doku, wie
HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors.
Und verwende asynchrone Programmierung bei sowas. Das ist essentiell.
Mir is nich klar, was Du für eine Antwort Du Dir wünscht.. aber ich nehm mal kein Blatt vor den Mund 😃
- Der Code ist super anfällig für SQL Injection ⇒ [Artikelserie] SQL: Parameter von Befehlen
- Dem Code fehlt jegliche Struktur, auch fehlt der Sinn von OOP
- Du beachtest keinerlei Namensregeln/-empfehlungen in C#; Du scheinst aber mal mit C? was zutun gehabt zu haben, weswegen Du solche Prefixe wie str für Strings verwendest - hat in modernem Code nix zu suchen
Es ist klassischer Spaghetti-Code, aber denke, dass Dir das bewusst ist 😉
Wie man es machen würde:
- Verantwortlichkeiten trennen (DB Code, Email, Logik..) und damit Code in Klassen umsetzen
- Man verwendet den Typ
stringund nichtString, ausser Du willst die Eigenschaften von String haben (zB Überschreibbarkeit) - Keine DataTables (verwendet man seit >10 Jahren nicht mehr), sondern mit ADO.NET arbeiten, zB EF Core.
- SMTP ist quasi tot, bietet keinerlei Sicherheit oder Spamschutz → Hoher Missbrauch, kaum jemand bietet das noch als Endpunkt an
- Zu DateTime siehe [FAQ] DateTime vs. DateTimeOffset und der Umgang mit Zeiten in .NET
Die Community Version hat den gleichen Basis-Funktionsumfang wie Professional. Du musst wie in vielen Fällen aber hier eine Pay-Variante nehmen, sobald Du eine gewisse Firmengröße erreichst.
Enterprise organizations are defined as >250 PCs or > $1 Million US Dollars in annual revenue.
Es dient also letzten Endes Einsteigern, Studenten, (sehr)kleinen Firmen, Freiberuflern... in die Microsoft Welt einzutauchen.
Siehe offizieller Vergleich: Compare Visual Studio 2022 Editions
Ich verwende Enterprise (ich bekomm sie von Microsoft gestellt) und für den Alltagsentwickler lohnt sich das nicht.
Live Unit Testing, Code Coverage sind aber echt tolle Features.
Willst Du gern etwas Geld los werden, einfach als Inspiration: https://www.betterplace.org/de 😃
Muss auch nicht installiert sein, wenn man die Self Contained Variante als Deployment nimmt. Ist also zwangsweise kein Fehler..
Aber... steht im Link...
Hab ich wohl falsch in Erinnerung gehabt.
Zeitplan: Microsoft will Enterprise-Kunden 2026 auf neues Outlook umstellen
Die automatische Umstellung erfolgt aber im April 2026, mit der Option zurück zu gehen.
Zitat von fichz
Gibt es generell Infos, wann das neue Outlook kommen wird?
Das ist schon da. Mail und Calendar App auf Windows 11 sind zum 31. Dezember 2024 abgekündigt; ab da das neue Outlook (für alle, die bisher Mail genutzt haben).
Für Business Kunden ist das Ende - laut verschiedener News - vom "Outlook Legacy" der 31. März 2026.
Zitat von fichz
Aber gibt es einen Richtwert ab wann man von "Massensenden" spricht?
Interpretation der großen Anbieter ist: alles, was automatisiert ist.
Das Exchange-Limit bei Microsoft, das sich auf den Graph im Userkontext auswirkt, sind 30 Nachrichten pro Minute und ein Recipient Limit von 10.000.
Das hört sich erstmal viel an, aber die Limits sind mit entsprechenden Automatismen (zB ERP) schnell erreicht. Klar, für Mini-Dinge mag das reichen, man sollte es aber im Hinterkopf haben.
Ja das ist ziemlich "bescheiden", dass es aktuell nicht zur Verfügung gestellt wird. Kann man halt nur hoffen, dass dies vielleicht noch kommt.
Muss kommen. Die Kritik am neuen Outlook is so groß, bricht so viele Prozesse- hat schon sein Grund, wieso das schon 2 mal verschoben wurde, alle aufs neue Outlook zu zwingen.
Es geht auch erst seit kurzem, dass man ein Postfach verbinden kann, das keine Outlook-Lizenz hinterlegt hat, wie es sonst immer der Fall und bei vielen Firmen war (aufgrund der verschiedenen Lizenzierungsmodelle).
Wäre das ein Add-In für das Outlook New, welches ich dann irgendwie ansprechen kann?
Du kannst basierend auf JavaScript, das ja COM-Addins ersetzt hat, Office Addins schreiben und über die O365 Admin Konsole entsprechend als internes/private Addin verteilen. In dem Addin selbst kannst dann zB Textfelder anzeigen, die der User ausfüllen soll und die Mail anschließend via makeEwsRequestAsync senden.
Das ist dann nicht der "echte" Office Editor, dann arbeitest mit Templates. Alternativ kannst mit dem Addin auch nen API-Request an einen Service von Dir schicken, dort das E-Mail Template aufbauen und dann via Graph/ACS verschicken.
Das war zumindest meine/unsere Evaluierung.
X-Unsent 1 wird einfach im neuen Outlook (noch/mit Absicht?) nicht unterstützt/vergessen.
Für das Versenden im Hintergrund verwende ich nun die Graph API (welche man meines Wissens ja aktuell verwenden sollte), welche super funktioniert. Somit wäre das erste Problem beseitigt.
Das war eigentlich immer nur ein Workaround. Aber zugegeben ist das der einzige Workaround, den man im Kontext des Users aktuell immer noch machen kann. Es war aber nie für das Massensenden gedacht, deswegen auch die sehr harten Limits, die evtl auch gesenkt werden sollen. Für Massenversand ist der Azure Communication Service gedacht.
- Gibt hierzu irgendwelche "Best Practices"?
Nicht von Seite Microsoft.
- Wie macht ihr es sonst?
Hintergrundmails immer über die entsprechenden APIs ohne Desktop-Anwendung.
Für Outlook New gibt es derzeit keine Lösung es als Editor vor dem Absenden, wie man es bisher von Outlook gewohnt war, zu automatisieren; ich hab das mal vor einiger Zeit aufgrund eines Projekts recherchiert, und nur Hacks gefunden, die zu dem Zeitpunkt auch nicht mehr funktioniert haben.
Eine relativ einfache Option ist es aber ein Outlook Add-In zu schreiben, sodass der User so eine Quasi-Editor-Funktion in Outlook hat.
Ein Hinweis: in fast jeder Runtime-Technologie gibt es einen Standard, die man loggt. In .NET ist das das ILogger-Interface.
Docs: Logging in C# and .NET
Hier selbst was zu erfinden, ist fast immer der schlechteste Weg.
Das ILogger Interface ist unabhängig und standardisiert, sodass verschiedene "Log Consumer" angehängt werden können.
Der Stelle, an der Du loggst soll egal sein, wohin das Log später geschrieben wird. Du kannst dann zB das sehr verbreitete Serilog als Log-Provider verwenden, das dann in verschiedene Sinks schreiben kann.
Willst Du das Log selbst konsumieren in Deiner App, dann würdest Du eine ILoggerFactory erstellen, und dann in Deiner GUI darauf hören.