[...]dann musst du deinen eigenen link richtig lesen[...]
Ich hab das schon richtig gelesen, du auch? ;)
Auf der von mir verlinkten Seite steht folgendes
Zitat
.NET Framework 4.8 is the latest version of .NET Framework and will continue to be distributed with future releases of Windows. As long as it is installed on a supported version of Windows, .NET Framework 4.8 will continue to also be supported.
Also es wird weder eine spezifische Version noch sonst genauere Details genannt, ab wann .NET nicht mehr unterstützt wird. Und da auch verschiedene Komponenten von Windows selber auf .NET basieren, geh ich (Stand jetzt) davon aus, dass es kein zeitnahes Supportende geben wird!
Solltest du andersweitig Informationen haben, so freu ich mich auf entsprechende Quellen. Alles andere kann ich dann nur unter Gerüchte und Co verbuchen.
Darüber hinaus wurde die Aussage, wonach .NET Framework weiterhin seinen Platz haben wird, auch direkt von MS Mitarbeitern bestätigt, u.a. von Immo Landwerth (seines Zeichens Program Manager des .NET Teams bei Microsoft).
Er hat das u.a. im Gespräch mit David Tielke in folgendem Video vor knapp 2 Monaten genau so geäußert, dementsprechend kann von Abkündigung keine Rede sein!
Das Video findet sich unter DevDaily 100 - .NET und .NET Core mit Immo Landwerth, die Aussage ungefähr bei Minute 56:00
Aber insgesamt will ich darüber nun auch keine große Diskussion führen, sondern ich wollte nur deutlich machen, dass das klassisches .NET Framework nicht abgekündigt ist sondern wohl noch länger erhalten bleiben wird und man auch darauf basierende Projekte weiterführen kann.
.NET 5 und seine Nachfolger werden aber ganz klar die Zukunft sein, weil dort alles an Innovation und Co stattfinden wird. Am Ende hängt es davon ab, was man machen möchte und was einem wichtig ist.
.net framework ist komplett abgekündigt und es gibt nur noch den lebenslauf von .net 5
Nur um das mal klar zu stellen...Diese Aussage ist so nicht richtig.
Das klassische .NET Framework (aktuell v4.8) ist NICHT abgekündigt, sondern wird nur nicht mehr proaktiv weiterentwickelt. Aber sehr wohl noch mit Bugfixes, Sicherheitspatches und notwendigen Anpassungen (z.B. Unterstützung für TLS 1.3) versorgt und das wird wohl auch noch viele Jahre so bleiben, da es als integraler Bestandteil von Windows 10 gilt und somit auch direkt an dessen Lebenszyklus hängt. So lange also Windows 10 lebt, wird auch das klassische .NET Framework leben.
Siehe .NET Framework Support Policy (unter dem Punkt "Support lifecycle")
Das ist IMHO ein deutlichter Unterschied zu "abgekündigt" ;)
Nichtsdestotrotz seh auch ich in .NET (Core) 5 die Zukunft und wenn ich die Wahl hab, dann würde ich das wählen.
Und noch ein Hinweis zu .NET Standard...
Der wurde quasi mit dem Release von .NET 5 auch wieder "abgeschafft", d.h. es wird keinen Nachfolger von .NET Standard 2.1 geben, wenn ich das richtig verstanden habe.
Dementsprechend muss man sich damit wohl nur befassen, wenn man noch das klassische .NET Framework (was nur max. .NET Standard 2.0 unterstützt) oder .NET Core ≤ 3.1 unterstützen möchte (z.B. in Form von Nuget Paketen)
Siehe The future of .NET Standard
Ich find es schade, dass Linux nicht unterstützt wird bzw. davon keine Rede ist. Nicht das ich das nun unbedingt brauch, aber wäre irgendwie nett gewesen ;)
Aber ansonsten schließ ich mich der Aussage von T-Virus an. Etwas worauf ich schon länger warte.
Eine Alternative KANN an dieser Stelle dotPeek von Jetbrains sein. Neben der Möglichkeit Assemblies zu dekompilieren, kann man auch von einer Assembly PDB-Dateien generieren lassen und diese dann via lokal laufendem Symbolserver beim Debuggen via Visual Studio nutzen.
Zu beachten ist hierbei natürlich, dass man nur den kompilierten und evtl. optimierten Code debuggen kann, der sich evtl. deutlich vom Code bei Github und Co unterscheidet. Sollte aber bei Fehlersuche und Co keine entscheidende Rolle spielen IMHO.
wenn du auf die UAC verzichten willst, dann solltest du deine Anwendung einfach in einen Ordner installieren in den der Benutzer schreiben darf. Im einfachsten Fall einfach unterhalb des Benutzerprofils unter C:\Users\{MyUser}\{MyApp}.
Läuft deine Anwendung von da, dann kannst du einfach ohne UAC Dateien kopieren und austauschen, da der Benutzer die notwendigen Zugriffsrechte schon hat (AFAIK macht es Chrome ähnlich, damit ein Update still im Hintergrund erfolgen kann).
Erscheint mir zumindest einfacher, als die UAC irgendwie umgehen zu wollen, was IMHO nicht oder nicht ohne Workarounds möglich ist.
hast du schon mal in den Event Log (via EventViewer bzw. Ereignisanzeige) vom Betriebssystem selber nachgeschaut? Bisher hab ich da immer einen Hinweise auf die Ursache gefunden, wenn sich eine .NET Anwendung scheinbar grundlos verabschiedet hat.
Denn nur der Teil "x-netscan-auth: xxxxxx" beschreibt den Header im curl-Aufruf, die URL is dagegen einfach die Adresse unter der der Endpunkt erreichbar ist und somit nicht Teil des Headers.
Grüße, HiGHteK
PS: REST-Services lassen sich IMHO sehr viel komfortabler mittels RestSharp komsumieren..so als kleiner Tip ;)
eventuell hilft ein Blick in den Eventlog des Systems (gilt natürlich nur für Windows) auf dem die Exception aufgetreten ist. Vorallem nicht gefangene/behandelte Exception, die eine Anwendung zwangsweise beenden, werden dort mitunter protokolliert.
Ach die Treffer kann man sich auch anschauen?! ;)
Aber danke für die Hinweise, ich schau mir das alles nun mal in Ruhe an. Ist doch recht viel neues dabei..
Kaum zu glauben, aber die Idee hatte ich natürlich auch...
Trotzdem hat mich die Erfahrung gelehrt, dass die Anzahl der Googletreffer kein Indikator für die Qualität einer Umsetzung ist. Deswegen hatte ich die Frage nochmal hinterhergeschickt, weil hier sicher der ein oder andere schon mehr als eine REST-API mit Authentifizierung und Autorisierung umgesetzt hat und aus der Erfahrung heraus vielleicht noch etwas dazu sagen kann.
Aber ok, ich denk ich komm damit erstmal weiter und belass es dabei.
danke für die Informationen, dann kann ich zumindest darauf basierend schon mal meine Suche erweitern. Ich hoffe das sich dabei auch alle noch offenen Fragen erledigen bzw. das die Umsetzung im genannten Szenario sich aus den Informationen erschließt.
Kann evtl. noch jemand etwas dazu sagen, ob NancyFX sich für ein solches Szenario (tokenbasiert, OAuth2, etc.) eignet? Muss gestehen, dass ich mich mit dem Thema Authentifizierung und Autorisierung noch nicht so intensiv auseinander gesetzt habe und hier für weiterführende Links, Informatione und Co dankbar wäre.
Folgendes Szenario bereitet mir nun schon einige Tage Kopfzerbrechen und ich komm mit den Informationen aus Suche und Dokumentation irgendwie nicht weiter und hoffe hier eine hilfreiche Anregung zu bekommen.
Es existiert ein REST-API basierend auf NancyFX, welche eine Authentifizierung mittels Forms-Authentication anbietet. Also ein Benutzer kann sich mittels Username + Password anmelden und dann verschiedene Aktionen durchführen.
Diese Schnittstelle soll langfristig sowohl von Webanwendungen wie auch Apps genutzt werden.
Der erste (Test)client soll dabei auf ASP.NET MVC Core basieren und hier beginnt mein Verständnissproblem. Während z.B. bei einer SPA der Client direkt mit der REST-Schnittstelle kommuniziert, geschieht dies ja bei der ASP.NET Anwendung nicht, da diese Anwendung sich nach meinem Verständnis zwischen Client und Schnittstelle befindet und die Kommunikation mit der Schnittstelle übernimmt. Und genau da liegt mein Problem...Denn so landen ja auch die Authentifizierungsinformationen nicht am Client sondern im Datenzugriff der ASP.NET Anwendung und ich müsste diese von Hand immer einem Benutzer zuordnen, was ich aber gern vermeiden wollen würde, da es sich nach meinem Verständnis nicht sauber anfühlt.
Vielmehr suchte ich bisher nach einer Art Möglichkeit, wo die ASP.NET Anwendung sich mehr wie ein Proxy verhält und die notwendigen Authentifizerungsinformationen mehr oder weniger durchschleust, so dass diese beim Nutzer liegen und von der Anwendung nur für die Kommunikation verwendet werden können.
Gibt es bereits vorhandene Möglichkeiten oder ist ein solches Vorgehen eher ungewöhnlich / nicht empfohlen? Gibt es im besten Fall Alternativen, weiterführende Informationen (Dokumentation, Tutorials, etc.) oder wenigstens einen (Fach)Begriff unter dem man dazu suchen kann?
Wäre es an dieser Stelle nicht sehr viel einfacher fertige HTML-Seiten zu generieren auf Basis der vorhandenen Daten? Könnte mir an dieser Stelle sehr gut den Einsatz von Razor als Templateengine vorstellen.
Dann brauchst einfach nur Templates erstellen (welche sich ja auch via CSS formatieren lassen), diese mit den entsprechenden Daten füttern und anzeigen lassen. Allerdings funktioniert dies nur, wenn die Daten statisch angezeigt werden, d.h. über die Weboberfläche ist dann wahrscheinlich keine Aktualisierung der Daten möglich. Aber auch hier könntest dann drüber nachdenken, ob du einfach eine Browserengine embeddest und die Anzeige der generierten HTML-Seiten darüber realisierst.
Dann kommst quasi ganz ohne Webserver aus und kannst bei Bedarf die Anzeige aktualisieren...
Ansonsten klingt das für mich grundsätzlich nach Reporting, auch da gibt es bereits fertige Bibliotheken mit denen man entsprechene Reports in HTML, PDF und Co erzeugen kann. Evtl. lassen sich mit den Suchbegriffen auch noch nützliche Antworten finden.
Aber das nur mal als Anregung und Möglichkeit, dass ganze ohne einen Webserver zu realisieren. Klingt für mich irgendwie nach Kanonen und Spatzen ;)
Wie bereits gesagt wurde, hat die Bezeichnung "Attribut" im Umfeld von .NET eine andere Bedeutung.
Zitat
Ich möchte die Felder der Objekte in eine Datei speichern
Wenn es wirklich nur darum geht, dann kanst du dich auch mal mit dem Thema Serialisierung beschäftigen.Damit kannst du den Zustand eines Objekts binär, als XML, JSON, ... speichern.
MyNode soll irgendeine Eigenschaft besitzten anhand derer ich ein bestimmtes Form identifizieren kann, so dass das Form beim MausKlick auf den TreeView Node instanziiert /aufgerufen, irgendwas mit gemacht wird.
Ich würde an dieser Stelle einfach auf DependencyInjection bzw. das MEF zurückgreifen. Alle Elemente, die angezeigt werden müssen, werden mittels gemeinsamer generischer Schnittstelle abgebildet, im einfachsten Fall sowas wie
public interface INode
{
void Show();
}
Die Implementierungen können nun relativ einfach von deiner Basisklasse ableiten
[NodeMetadata("NodeA")]
public class NodeAForm : MyGenericForm<AObject>, INode
{
public void Show()
{
//...
}
}
und via Attributen bzw. Metadaten kann deklariert werden, für welchen Node sie zuständig sind.
Nun kann man sich via MEF alle Implementierungen einer Schnittstelle (z.B. INode) holen, die Metadaten auswerten und so die zu einem Node passende Implementierung ermitteln.
Nun einfach Show() an dieser Implementierung bzw. Instanz aufrufen und voila...Ohne Reflection, switch case oder sonstigem bekommt man die zu einem Node passende Form angezeigt. Und erweiterbar ist das ganze auch sehr einfach, da man für jeden neuen eindeutigen Wert einfach eine neue Implementierung der Schnittstelle erstellt.
Mir ist durchaus bewusst, dass meine Erklärung sehr komprimiert ist und evtl. nicht alle angesprochenen Technologien und Vorgehen bekannt sind, aber mit etwas Eigeninitiative sollte sich zu allem was finden lassen und bei konkreten Fragen einfach wieder hier im Forum nachfragen ;)
Danke nochmals für deine Hilfe.
Auch der zuletzt von dir angesprochene Aspekt ist mir bekannt, hätte das Problem aber nur unzureichend gelöst. Ich gebe auch gern zu, dass ich VB.NET bisher bewusst gemieden habe ;)
Aber wie bereits angesprochen konnte ich mein Problem sehr viel einfacher lösen, als nun extra eine Klasse in einem C#-Projekt anzulegen, um diese mittels dem existierenden VB-Projekt zu erweitern / zu nutzen. Ich hab tatsächlich nur einen kleinen Denkanstoss gebraucht.
Du weist schon das man in VB.NET auch locker jede C# DLL benutzen kann?
Ja dieser Umstand ist mir bekannt. Allerdings kann man VB und C# nicht innerhalb eines Projektes mischen und das Projekt mit der problematischen Servicereferenz ist halt ein VB.NET-Projekt. Und nur die Servicereferenz in ein C#-Projekt auslagern ging auch nicht, da da noch bisschen mehr (VB.NET)-Code dran hing.
Zitat von FZelle
Aber ganz abgesehen davon könntest du auch einfach jeden Webservice in eine eigene DLL packen,
dann kannst du den Namespace auch verändern.
Danke, genau das hab ich dann auch getan. Keine Ahnung warum ich nicht gleich daran gedacht hatte diesen monolitisch anmutenden Service aufzuteilen
ich hoffe ich bin hier mit meinem Anliegen richtig, auch wenn es nur bedingt mit der WCF zu tun hat, aber alle anderen Kategorien erschienen mir noch unpassender.
Folgendes Problem...
Aktuell muss ich eine ältere Anwendung pflegen, die komplett in VB.NET (hab selber bisher immer in C# entwickelt) entwickelt wurde. Diese nutzt verschiedene Webservices (Java+Tomcat+JAX-WS) via Servicereference, so dass alle notwendigen Klassen anhand der WSDL automatisch generiert werden.
Nach Aktualisierung der Servicereferenz tritt nun leider ein Fehler auf, weil 2 Klassen Query und query generiert wurden. Wie ich daraufhin lernen musste unterscheidet VB.NET hier nicht zwischen Groß- und Kleinschreibung und beschwert sich somit zu recht, dass es 2 Klassen mit dem selben Namen gibt bzw. das an einer Klasse Query ein Attribut mehrfach definiert wurde.
Gibt es irgendeinen Ausweg aus diesem Problem? Kann man dem Generierungsprozess irgendwie sagen, dass er die Typen bitte in verschiedene Namespaces packen soll, da diese auch innerhalb der WSDL in verschiedenen XML-Namespaces liegen?
Einzige Möglichkeiten, die mir bisher eingefallen sind, wäre entweder die Anpassung der Serverseite oder Umstellung des Projekts auf C# auf Clientseite...beides mit erheblichem Aufwand verbunden und somit nicht in meinem engeren Favoritenkreis ;)
Es ist zwar schon eine Weile her das ich mit DataTables gearbeitet habe, aber kannst du nicht einfach für die Spalte den DefaultValue setzen? Laut MSDN wird dann für jede neue Reihe automatisch der festgelegte Wert verwendet und müsste somit nicht mehr manuell definiert werden.
hab mir eben mal deine Testseite unter http://test.boxxnet.de/ angeschaut und bekomme diese leider nicht richtig angezeigt (siehe Navigationsbereich im Screenshot). Browser ist Opera in der Version 20.0.1387.91.
Aber ansonsten macht es einen guten Eindruck, werd ich die Tage mal ausprobieren und gegen ein kleines Projekt von mir laufen lassen.
da ich aktuell auch ein Projekt mit Prism umsetzen darf, hat mich die Frage interessiert und ich habe mal einen Blick in den Sourcecode von Prism geworfen.
Das Verhalten was du beobachtest, hat nichts direkt mit der Oberfläche zu tun. Aber bei dem DelegateCommand gibt es etwas wichtiges zu beachten...
Abonenten des CanExecuteChanged-Events werden vom DelegatCommand nur als schwache Referenz gehalten. Das heißt wenn sonst keine Referenz mehr auf dieses Objekt existiert, kann es passieren, dass der GC das Objekt abräumt, bevor der Event ausgelöst wird! Bindest du das Command an einen Button, so wird dieser als "harte" Referenz innerhalb der Oberfläche gehalten und es funktioniert wie erwartet.
Das Ganze steht auch so in der Dokumentation, siehe DelegateCommandBase.CanExecuteChanged Event (Remarks-Abschnitt)
ich hatte bisher noch keine Anstellung, bei der ich ausschließlich zu Hause gearbeitet habe. Allerdings schon die Möglichkeit einzelne Tage oder Stunden nach eigener Einteilung in meine eigenen 4 Wände zu verlegen.
Und ich muss sagen gerade dieser hybride Ansatz aus normalem Firmenarbeitsplatz mit Möglichkeit für Homeoffice hatte für mich einige Vorteile. Angefangen von mehr Freiheiten beim Vereinbaren privater Termine (Arzt, Handwerker, Lieferungen, etc.) bis hin zu effizientem Arbeiten in einer ruhigen Umgebung, wenn man mal ein anspruchsvolleres Problem zu lösen hatte.
Allerdings ist natürlich nicht alle Gold was glänzt...Die Kehrseite der Medaille gibt es natürlich auch. Man muss recht klar und deutlich eine Trennung zwischen Arbeit und Privatleben schaffen, da sonst schnell Probleme auftreten weil manch einer der Meinung sein könnte, man wäre dann immer erreichbar und in der Lage schnell was zu erledigen. Dem muss man evtl. ganz bewusst entgegen steuern, sonst sitzt man auch am Wochenende an irgendwelchen "total wichtigen" Sachen und baut unnötig viele Überstunden auf ;)
Die Elemente, die in l2, aber nicht in l1 enthalten sind, kann man auf die gleiche Weise ermitteln. Man muss nur die beiden Listen-Variablen vertauschen.
Danke für die ergänzende Anmerkung. Ich gebe zu das meine zusätzliche Bemerkung etwas unglücklich formuliert ist, aber genau darauf abzielen sollte. Ich ging auch einfach davon aus, dass das jedem klar sein sollte, spätestens beim Blick in die verlinkte Dokumentation ;)
ich glaube der Beitrag bewegt sich hart an der Grenze zu einem Grundlagenbeitrag.
Aber als kleiner Hinweis...
Wenn die Spaltennamen in jeweils 2 Listen mit Strings vorliegen und du nur die Unterschiede wissen möchtest, so kannst du der Einfachkeit halber auch auf Enumerable.Except zurückgreifen.
Als Ergebnis bekommt dann eine Auflistung der Unterschiede, welche du problemlos weiterverwenden kannst (z.B. für die Anzeige an der Oberfläche).
Beispielcode:
List<string> l1 = new List<string>(new string[] { "Foo", "Bar", "Baz" });
List<string> l2 = new List<string>(new string[] { "Foo", "Bar" });
List<string> diff = l1.Except(l2).ToList(); //diff enthält nun nur noch "Baz"
Edit: Ich muss meinen Lösungsvorschlag einschränken...Bei Enumerable.Except werden nur die Elemente zurückgegeben, die in l1, aber nicht in l2 enthalten sind. Elemente die in l2, aber nicht in l1 enthalten sind, werden nicht zurückgegeben!