Ist es irgendwie möglich mittels C# Hersteller und Modell von Druckern / Kopierern mittels IP abzufragen?
"Ist es möglich"-Fragen können immer mit Ja beantwortet werden; einfach nur eine Frage des Aufwands.
Zitat von Little Tester
Wie müsste man vorgehen? Einige Setup-Programme der Hersteller können das ja und listen diverse Modelle bei einer Netzwerkinstallation auf.
Paar Minuten Google sollte Dir zeigen, dass es hier keinen Standard gibt, auch nicht auf Protokoll-Ebene.
Das sind spezifische Implementierungen der Hersteller; natürlich können die Setups das. Und Windows kann das, weil es generische Treiber der Hersteller hat.
Du musst also entweder eine OS-API nehmen, oder Dir selbst einen Baukasten der Hersteller-Implementierungen aufbauen.
Aber wie gesagt: paar Minuten Google und Du findest dazu alle Erkenntnisse, die Du eigentlich brauchst.
Wenn es also wirklich nur innerhalb einer Solution ist, dann schließ VS, lösch den ".vs" Ordner und starte die Solution neu.
Lokale IDE Infos speichert VS niemals in den Projektdateien, sondern im Local Solution Cache, wo zB. auch die Infos liegen zu aktuell geladenen Tests, offene Tabs etc...
Dann kommt es noch auf den Anwendungstyp an, da es in ASP.NET Core andere Best Practises gibt als zB. in WPF für das "generelle Loggen".
Serilog zB kann man bei den meisten Applikationstypen als Standard Factory Logger registrieren.
Mit Deinem aktuellen Code fängst Du die Exception lokal ab, aber wie gesagt, gewisse Exceptions kannst Du nicht fangen, egal wo.
Und dazu gehören die meisten Speicherverletzungsmeldungen, wie Du es im Startbeitrag gefragt hast.
Wenn Du eine andere Frage hast, wie man generell Exceptions fängt, dann ist das mit dem erste Teil dieses Beitrags beantwortet :-)
Nein. Meine Frage hat nix mit Kommunikation zwischen Forms zu tun...
Ich werd jetzt zwar die dritte Person sein; aber doch: wenn man Deinen Startbeitrag durchliest, dann hat das sehr wohl mit der Kommunikation von 2 Forms zutun.
Zitat
Beim Schließen des 2. Forms soll der Text des Buttons, welches vorher angeklickt wurde, sich ändern.
Habt ihr eine Tipp für mich, wie ich das am besten anstellen kann?
Musst was auf der 2. Form callen; und die Identifizierung vom Button is ja einfach nur ne gespeicherte Referenz.
Ist auch überhaupt nicht schlimm, dass Du noch mit alter .NET Technik unterwegs bist; vermutlich sind das die meisten Entwickler.
Das ist vollkommen okay.
Aber dann schau Dir doch einfach gewisse Themen wie LTS an, wenn sie neu für Dich sind, statt einen Mischmasch aus zusammenhanglosen Fehlinfos zu schreiben :-)
Das hilft Dir nicht, und anderen erst recht nicht :-)
Vorweg: Hab das Thema in ein eigenen Thread verlagert
Zitat von T-Virus
Mir geht es nicht um DateTime/DateTimeOffset.
Das es die seit .NET 2.0 gibt ist mir klar, da ich schon seit 2007 mit .NET arbeite.
Mir geht es um DateOnly/TimeOnly.
Die Historie zeigt allgemeinen Changes zwei Lager:
- Devs, die sich selbst aktuell halten und Changes adaptieren
- Devs, die das nicht tun, weil sie zB die Changes gar nicht mitbekommen
Die Entwickler von großen Libs, von Open Source Projekten gehören in 99,9999% zum ersten Lager, weshalb hier jegliche Ökosystem Changes auch schnell verbreiten; meistens als kompatible Fast Forward Changes. Daher siehst Du hier in den ensprechenden Preview-Versionen jetzt, nach wenigen Tagen, schon die ersten Implementierungen.
Entsprechend ist dann auch die Verbreitung hoch, wenn agile, moderne Projekte solches Übernehmen.
Und dann gibts da halt noch die - ich nenn sie mal - klassische Wasserfall-Welt von .NET; oft auch mit gestandenen .NET Entwicklern, die sich aus verschiedenen Gründen vielleicht nicht mehr so häufig über Changes informieren; Code oft jahrelang nur Pflegen, teilweise erweitern.
Da wird man solche Changes halt deutlich langsamer sehen.
Dass man nun in der Datenbank ein DateTimeOffset-Feld, das bisher fürs Geburtstag hergehalten hat, nun so schnell wie möglich sofort in ein DateOnly Feld umwandelt; ja, vermutlich bisschen übers Ziel hinaus geschossen.
Unnötig und nicht zweckdienlich.
Aber Deine allgemeine Aussage, dass das 2-3 Jahre dauern wird: na, da zeigt wie gesagt die Historie ein völlig anderes Verhalten :-)
Würde entsprechend nicht darauf setzen; das geht schneller, viel schneller.
Zitat von T-Virus
Gibt es solche Api Erweiterungen in jeder Version von .NET oder nur bei LTS Versionen?
Ähm, wat? Nein, Nein, LTS hat damit gaaar nichts zutun.
LTS hat nichts mit Content zutun. LTS bedeutet Long-Term-Support. Da gibts auch keine Probleme.
Hier gehts also nicht darum, dass neue Inhalte kommen oder um Kompatibilitäten, sondern um Patches.
Du vermischt da nun einige Sachen, die in sich nichts miteinander zutun haben.
Größere Änderungen aller Art können mit jedem Major Update kommen (beachtet man die SemVer Konventionen, die .NET erfüllt).
Schau Dir nochmal an, was der Sinn einer LTS ist und was er mit Content Changes zutun hat :-)
Zitat von T-Virus
Entsprechend müssten hier die Libs Entwickler zukünftig auch abwägen welchen Weg man gehen will.
Auch das nicht.
Für Entwickler ändert sich mit LTS genau: nichts.
Entwickler können komplett wie bisher agieren: Geringste Vorgabe der .NET Version, die inhaltlich sinnvoll ist.
LTS hat auch hier wirklich nichts, gar nichts zutun.
Zitat von T-Virus
Da .NET 6 die erste LTS Version im neuen Versionszyklus wird, wird sich erst mit den nächsten Versionen zeigen ob/wie hier dann die zukünftige Libs Entwicklung laufen wird.
Entsprechend fehlen hier auch noch die praktischen Erfahrungen, die sich erst noch zeigen müsssen.
Nein, auch das nicht :-)
Die praktischen Erfahrungen von SemVer sind schon Jahrelang vorhanden, auch hier LTS: keinerlei Aktien.
.NET ist hier auch nicht das einzige Ökosystem, in dem das so ist; das ist quasi in allen Ökosystemen so.
Dass es in .NET überhaupt LTS gibt liegt an der Release Geschwindigkeit: diese ist nun eher dem agilen Modell entsprechend, deutlich häufiger; es gibt alle 6 Monate ein Major Release und jedes zweite (immer gerade Zahlen) ist ein LTS.
Da braucht .NET LTS im Sinne des reliability engineering, wie man es eben aus anderen Ökosystemen gewöhnt ist. Die Bindung an den Betriebssystem Support, wie es mit .NET Framework der Fall war, ist entsprechend ja weggefallen.
DateTimeOffset existiert seit .NET 2.0, also seit 2006 und trotzdem verwenden viele .NET Entwickler DateTime, weil sie nicht verstehen / wissen, welcher Fehler in DateTime steckt :-)
Aber Microsoft hat das damals auch nicht gut gemacht; man hätte den Typ abschaffen müssen oder zumindest viel härter informieren.
Ich seh fast täglich fehlerhafte APIs mit DateTime in Reviews. Ich hatte schon Kunden, die haben zehntausende von Euros in Fehlersuchen investiert und nachher wars die falsche Verwendung von DateTime, Time Zones und Zeitformaten.
Was ich damit sagen will:
In den Libs wird das sehr schnell kommen; in den Köpfen vieler vermutlich weniger :-)
Das zeigt ja auch so bisschen zumindest Deine Antwort :-)
Auch hier vielleicht nicht die Vermutung aufstellen, sondern zB nen Blick auf GitHub werfen.
Einige große Libs und zB auch Microsoft Produkte (zB Entity Framework Core) haben bereits in ersten Vorab-Versionen die neuen Typen in fast-forward / non-breaking Change APIs.
Und .NET 6 is nich mal released, sondern aktuell in prev 6 (seit prev 4 mit den neuen Typen).
Wenn DateTime* jetzt noch zusätzlich TimeOnly liefert macht es die Nutzung von DateTime* nur komplexer.
Ganz einfache Regel:
DateTime hat überhaupt keine Daseinsberechtigung mehr, ausser Legacy Code.
DateTimeOffset all the way.
Zitat von T-Virus
Und zukünftig wird man dann auch zwischen TimeSpan/TimeOnly hin und her konvertieren müssen.
Es macht immer mehr Sinn sich erst mal die Klassen und deren Zweck anzuschauen, statt sowas zu schreiben.
Denn TimeSpan hat mir TimeOnly wirklich gar nichts am Hut und da wird man auch nichts konvertieren müssen :-)
90% des Beitragsinhalts stimmt nich, weil Du Dir das nicht angeschaut hast :-) Nimm Dir doch erstmal 2 Minuten vor dem Post Zeit, les es Dir durch: dann wirds Dir klar.
Zitat von T-Virus
So ganz klar ist mir also noch nicht warum nun TimeOnly eingeführt wird.
Nach DateOnly / TimeOnly wird seit ca. 2005 gefragt und es gab immer wieder große, sehr aktive GitHub Diskussionen dazu, wie man es implementiert.
Gab auch schon erste Versuche bei .NET Standard dazu, hat das dann aber verschoben.
In .NET sind Zeiten eigentlich ganz klar strukturiert (lässt man Legacy weg)
- DateTimeOffset für absolute, eindeutige Zeitangaben
- DateOnly und TimeOnly für individuelle, nicht-eindeutige Zeitpunkte
- TimeSpan für Zeitdauer
public List<String> strlOtherFilename;
public List<String> OtherFilenames
{
get { return strlOtherFilename; }
}
Damit hast Du eine Eigenschaft mit einem expliziten Feld erzeugt. Aber:
- Felder sollten (ausser in ein paar Ausnahmen) immer private sein
- Das Feld ist unnötig, Dir reicht ein get mit einem hidden field => public List<String> OtherFilenames {get;}
Ansonsten noch Feedback an den Code:
- Du disposed die Handles nicht, zB bei den Streams -> kann zu Memory Leaks / Memory Exceptions führen
- Kannst Dir die ganze Arbeit fast vollständig sparen, wenn Du System.Text.Json verwendest, das zudem viel performanter und schlanker ist.
Jo, für das Vorhaben ist mein Link das richtige.
Das Windows Service Template is da zeitlich und technologisch schon paar Jahre überholt; würde man nur noch machen, wenn man die alten Windows Service Templates verwenden *muss*.
Les mal Deinen Text und stell Dir vor, dass wir Dein Projekt und Deine Anforderung nicht kennen.
Würdest Du es selbst verstehen, was das Vorhaben und was das Problem ist? :-)
Ich hab nicht im Ansatz verstanden, was Du insgesamt vor hast, geschweige denn, was Dein Problem ist.
Aber ein WinForms und ein Windows Dienst kann beides in der gleichen Solution sein; abgesehen davon, dass man seit vielen vielen Jahren das Windows Dienst Projekt gar nicht mehr braucht, sondern dafür das ASP.NET Core Projekt mit Hosted Service verwenden würde. Hosten von ASP.NET Core in einem Windows-Dienst
Tipp: [Hinweis] Wie poste ich richtig? -> 5. Problem genau beschreiben - inkl. genauer Fehlermeldung - und konkrete Fragen stellen
Ja, laut Google ist das ein 4K UHD Display.
Und weil 4K halt für normale Büroaufgaben total unnütz ist, skalieren alle Betriebssysteme entsprechend - damit man kein Adler sein muss.
Selbst mein XPS 13 skaliert auf 125% mit 1440p Display.
Mit diesem komischen Windows-Verhalten wenn Du Fenster verschiebst musst aktuell leben.
Mit Windows 11 soll das ja besser werden.
Zitat
(Käsekuchen wolltest Du ja nicht dazu).
Esse nichts mit Zucker oder anderes süßes Zeug, danke :-)
Man kann da nich erwarten, dass eine >25 Jahre alte Grund-Technologie alles unterstützen wird; gerade bei sowas wird man mal eine Migration ins Auge fassen müssen....
Zitat
ändert sich die Skalierung des Programmfensters.
Kann an .NET liegen; muss nicht.
Kann auch an den Windows Grafiksettings liegen, gerade wenn man unterschiedliche Monitore hat.
Windows skaliert / reagiert komisch, wenn man zB Fenster von einer 125% Bildskalierung auf Monitore mit einer 100% Skalierung verschiebt...
Will man hier ein flüssiges Verhalten, müssen alle Monitore mit der gleichen Skalierung laufen.
Und 4K auf 17 Zoll.... auch eher auf das Marketing reingefallen, wenn ich das so sagen darf :-)
"Error deleting /bin/obj/"
Pfad /bin/obj/ manuell löschen, dann gehts.
In VS2022 solls einen Clean-Setup geben, das bei einem Project / Solution-Clean automatisch automatisch bin/obj löscht.
Hab das bisher nur mit der myCSharp Foren-Solution versucht; aber leider noch nicht gefunden. Wird viele Probleme in Zukunft mit Solutions lösen.
Zitat von BerndFfm
Woran das liegt weiß ich nicht. Hat da jemand eine Idee ?
Gibt keine 100% Run-Sicherheit für Apps.
Für nen "echtes" Background-Verhalten brauchst zumindest auf iOS ne System-Allowance, die aktuell nur Musik- und Navi-Apps erhalten (oder sowas wie eben Corona Warn App durch ne extra API).
Nervt mich bei einigen Apps, wie zB. OneDrive, das nur synct wenn die App "offen" ist, also nicht manuell geschlossen wurde.
Ich kenn zumindest noch Shiny (shinyorg/shiny), das das Handling von Background Services mit Xamarin vereinfacht.
Damit Du Dir das Encoding nicht verhaust (und Dich auch im nichts kümmern musst, kannst Du einfach mehrere Streams mergen.
Dazu gibts die CopyTo Methode. Und damit auch nichts blockiert gibts async/await und CopyToAsync
await using var targetStream = File.Create(targetFilePath).ConfigureAwait(false);
foreach (var filePath in filePathCollection)
{
await using var fileStream = File.OpenRead(filePath).ConfigureAwait(false);
await fileStream.CopyToAsync(targetStream).ConfigureAwait(false);
}
Nun meine Frage, gibt es eineMöglichkeit wie ich das steuern kann ob die DLL mit 32-Bit oder 64-Bit verwendet werden soll, und das ganze weiterhin als eine einzige Appliaktion mit ClickOnce zu verteilen?
Du selbst kannst Das nur über die Compiler Optionen steuern (siehe auch Doku).
Im Prozess kannst Du das selbst nicht mehr ändern, weil zu diesem Zeitpunkt der Prozess schon geladen wurde.
Zumindest früher gab es Tools Exe-Dateien nachträglich entsprechend zu patche (CorFlags); aber zur Laufzeit geht das nicht (gilt aber IIRC nur für .NET Framework Dateien!).
Auch war es zumindest bei .NET Framework Anwendung möglich die jeweilige Anwendung über eine x64 bzw x86 Konsolen-Instanz zu starten, um eine AnyCPU-Anwendung mit der jeweiligen Bitness zu forcen.
Guten Abend, ich glaube es ist der Supergau für jedem von uns...
Prinzipiell gibts für sowas Quellcode-Verwaltungssysteme wie GitHub, sodass Fehler während der Programmierung quasi durch einen Roll-Back wieder korrigiert werden können.
Daher hat das im "professionellen Alltag" weniger Auswirkungen; eher nie ein Supergau - außer man verwendet es natürlich nicht.
Aber ja, beim Einstieg arbeitet man wenn überhaupt mit irgendwelchen Zip-Dateien als Sicherung....
Zitat von MarkusxX
Ich habe eine Klasse hinzugefügt und danach wieder Gelöscht, nun ist von Form1 kein Steuerelement mehr Sichtbar alle Buttons und Labels weg.
Das alleine kann eigentlich nicht dazu führen, dass Deine Form im Designer nicht mehr geladen wird.
Wenn Du die Klasse nicht gerade innerhalb Deiner Form erstellt hast, was Du hoffentlich eh nicht getan hast, hat das keine Auswirkung auf die Form.
Auch die beiden Zeilen, die Du hier als Warnings zeigst, führen eigentlich nicht dazu. Nur Errors wirken sich eigentlich auf den Designer aus.
Hab das gerade auch mit nem Demo Projekt nachvollzogen; trotz Warnings problemlos im Designer sichtbar.
Daher hast Du vermute ich a) zuviel gelöscht, das auch wir nicht wiederherstellen können oder b) noch Dinge getan, die Du vllt unbewusst gelöscht hast.
Ist wirklich nur fachlich und nicht persönlich gemeint; aber ich muss wirklich loswerden, dass ich schon lang nicht mehr solch einen Quellcode voller ungünstigen Umsetzungen und potentiellen Fehlerquellen auf so wenig Inhalt gesehen hab. Aber das Thema ist halt auch durchaus komplex, wenn man es richtig machen will.
Das ist riesig weit weg von dem, wie man das generell mit Sockets tun sollte und Lichtjahre weit weg, wie man sowas in 2021 machen würde :-)
Wie im anderen Thread schon von mehreren gesagt worden ist: nutz doch einfach die ASP.NET Pipeline für Dein Vorhaben.
10 Zeilen Code und Du hast was stabiles.
In Deinem Code stimmt fast nichts; weder im Aufbau des Listenings noch in der parallele Verarbeitung, die Du haben wolltest (Wie mache ich einen Server Multitaskingfähig?) .... und auch ganz weit weg von der Doku. Es wirkt fast so, dass Du aus verschiedenen Quellen zeug zusammen kopiert hast, das in seiner Funktionsweise aber gar nicht zusammen passt.
Da solltest Du nochmal schauen, wie das ganze Zeug funktioniert. Du wirst ansonsten was bauen, was niemals stabil funktionieren wird.
Und ich sag Dir das wirklich in der Deutlichkeit, dass Du vielleicht doch erkennst, das was stabileres als Basis die bessere Lösung >für Dich< ist.
Wie es grob funktionieren sollte:
- Du erstellst einen Listener und wartest auf Verbindungen
- Sobald eine Verbindung kommt nimmst Du diese an; Verarbeiten tust Du sie aber nicht im gleichen Thread, sonst blockiert alles
- Du hörst auf weitere Verbindungen
Wie Du das erreichen kannst: im Endeffekt 80% Deines Codes wegwerfen und folgendes korrigieren
- Nach Listen() auf einen Port wird sofort zugehört, der Thread danach ist quatsch
- Das Threading ist hier völlig falsch eingesetzt; verwende BeginAccept() und arbeite mit Callbacks
- Lass am besten den ganzen Thread-Quatsch weg und arbeite mit Tasks
Aber wie im anderen Thread gesagt:
Du versuchst das Rad neu zu erfinden und das leider sehr instabil statt bestehendes zu nutzen.
Ich kann da Palladin007 nur beipflichten: so ein Vorgehen hat mehrere Design Fehler bzw. Design Risiken.
Reflection an für sich ist schon ein gewisser Overhead und Risiko; das muss man nicht künstlich durch stringifcation und objectification noch verschlimmern.
Der Grund warum es überhaupt Source Code Generators gibt sind eben die Risiken von Reflections (und noch 2-3..72 andere Dinge wie Performance).
Nehmt also den Weg des .NET Ökosystems an und verzichtet auf Reflections, wo es nur geht - und nutzt moderne Mittel.
Zitat von Palladin007
Dann aber bitte prüfen, ob's die Property gibt und nicht mit Exceptions für den Kontrollfluss arbeiten.
Der eigentliche Grund dieser Antwort: das ist ein enorm richtiger und wichtiger Satz, den man unbedingt betonen muss!
Woher soll das Script denn wissen, wenn die Werte in einer ganz anderen Reihenfolge versendet werden?
Null sind prinzipiell valide Werte und in HTTP erlaubt. Die meisten Bibliotheken lassen den Wert einfach beim Versenden Weg oder er ist leer.
Serverseitig wird dann null gemappt, wenn nach dem jeweiligen Key gefragt wird aber kein Wert übertragen wurde.
Die Reihenfolge darf keine Rolle spielen, weil diese bei HTTP-Anfragen generell nicht garantiert sind; weder beim Versenden noch beim Empfangen.
Spielt in Deinem Code die Reihenfolge eine Rolle, dann hast Du generell einen Fehler in der Verarbeitung. Da sind Folgefehler demnach nur eine Frage der Zeit; also machs direkt richtig: und halte Dich einfach an Standards. Dafür sind sie da.
HTTP Parameter haben immer ein Key-Value-Schema, sodass Du das problemlos anhand der Namen verarbeiten kannst und einen grundlegenden Fehler wie eine stupide Reihenfolge erst gar nicht machen musst.
Wenn Du es korrekt implementiert hast, wie es der Standard (in diesem Fall REST) vorsieht, dann kannst Du problemlos null-Werte empfangen.
In einem weiteren Schritt validierst Du Pflicht- und optionale Felder (nach ihren Werten).
Danach schreibst Du die Werte in die Datenbank; inkl. null, wo es erlaubt ist.
Das hat mit "der Ansicht von Abt" nix zutun; das würde einfach viele Standards "verletzen" und Dir sehr wahrscheinlich in Zukunft sehr viele Probleme machen.
Zitat
Zeichen in der Liste, das zeigt, dass dort keine Werte vorhanden sind und ergänzt werden müssen.
Sowas würde man in der UI mappen, aber niemals über "Datenlogik".
Nein, gibt es in der Reinheit, die Du hier vermutlich willst, nicht.
Ich hab die Erfahrung gemacht: hast Du eine Anforderung, dass eine Condition zu lang wird, dann stimmt meist was am Code Design selbst nicht.
Also ein Anzeichen, dass die Software Architektur fischig oder zumindest auf dem Weg dahin sein könnte :-)
Was Du aber immer machen kannst sind einfache Extension Methods
public static class Check
{
public static bool IsAnyNull(params object[] args) => args.Any(x => x is null);
}
und dann eben
int? a = null;
double? b = null;
string c = null;
if(Check.IsAnyNull(a, b, c))
{
// do it
}