In der Richtung (Perlen) kenne ich auch nichts in C#.
Wenn überhaupt umgekehrt. Von 2005 kenne ich Amazon: .NET Gotchas. Ist nicht mehr wirklich aktuell, enthält aber einige Beispiele was mit dem Framework gerne falsch gemacht wurde/wird. Wenn du dann nach googelst findest du auch z.B. bei Stackoverflow was dazu.
Was man sich sicher auch immer mal anschauen kann sind die neuen Features, die mit den Versionen hinzugekommen sind. Z.B. MSDN:New Features in C# 7.0
Allgemein kenne ich das nichts. Ich denke auch das es darin liegt, das das Framework eine Riesige menge an Features bietet. Und das was allgemeines zu machen, echt schwer ist. Was man schon mal häufiger finden, sind Bücher die sich in Unterschiedlicher Tiefe mit eine Technologie im .Net Frameworke auseinander setzen. Für WPF gibt es zb. Bücher die sich erst mal an Beginn er richten und die Grundlagen erklären, dann gibt es deutlich Ausführlicher, die sich eher an Leute Richten die die Grundlagen schon kennen und dann gibt es Bücher die auch wirklich hinter gründe Beleuchten und ins eingemachte gehen.
Wenn du vielleicht genauer sagst was du machen möchtest, kann man da vielleicht besser zu Antworten.
Hier mal was von Microsoft zu dem Thema.
Spiegel:Microsoft warnt vor staatlicher Totalüberwachung
Er findet da das HostingPanel.Wiki Assembly nicht (lauf Fehlermeldung), mal geschaut ob die Datei da vorhanden ist wo sie sein sollte und du auch den Pfad verwendest?
Hast du vlt. eine Ahnung wie das mit den "index1.cshtml.cs" funtioniert ?
Da scheint es ja so etwas wie ein viewModel zu geben.
Aber wie ich das bebutze und dann noch in die ApplicationDbContext einbinde weiß ich noch nicht.
Da weiß ich jetzt nicht was du damit. Aber ich denke, das hat jetzt nichts mit deinem Problem zu tun oder? Wenn es nichts mit deinem Problem zu tun hat, mache bitte einen eigenen Thread dafür auf. Das gestaltet es übersichtlicher.
Schau mal hier: stackoverflow:Get Types in assembly (error: System.Reflection.ReflectionTypeLoadException)
(Aus dem Link) Lass dir est mal genauer ausgeben was das fehl schlägt.
try {
// your code
} catch (ReflectionTypeLoadException ex) {
// now look at ex.LoaderExceptions - this is an Exception[], so:
foreach(Exception inner in ex.LoaderExceptions) {
// write details of "inner", in particular inner.Message
}
}
Und schau mal ob die EF Version in der WebConfig Stimmt.
Das schlimme ist eigentlich nur, dass es nur wenige Institutionen gibt, die soviel Geld und Kapazitäten haben.
Nun ja das wird ja gerade in den Beitrag angesprochen. Das es "relative einfach und günstig" ist.
youtube:Übernehmen Hacker bald die Macht? | Harald Lesch
Fand dich ganz Interessant und ich mag Harald Lesch. Aber ich muss gestehen, ich bin jetzt kein IT Sicherheitsexperte, das ich ein paar der Einschätzungen doch für Übertrieben halte. Bzw. wie es rüber gebracht wurde. Die Angriffe halte ich durch aus für möglich, aber die Darstellung, wie „einfach“ es sein soll komplette Netzwerk Infrastrukturen Lahmzulegen erscheint mir sehr Vereinfacht.
Was haltet ihr da von?
Hi Gimmick,
um es vielleicht mal mit einem anderen Ansatz zu erklären.
Die willst 3 Quellcode Branchen hab. (Dev, Main, Release)
Ich gehe jetzt einfach mal davon aus, Dev ist deine Brache in der du Features für die Zukunft Entwickelst. Da sind teils Features, drin die noch nicht Komplett Fertig sind. Oder wo ungewiss ist ob sie in der Form wirklich auf Markt kommen. Da soll dann die QS noch mal drüber schauen. Und man kann es vielleicht einigen Kunden schon mal zeigen oder auf Messen vorführen.
Main könnte deine Branche sein, wo feststeht, das ist der nächste „Main“ Release Stand. Da sind neue Features drin, die Schon Fertig sind. Und sie wurde vielleicht ein paar Test Kunden zu Verfügung gestellt.
Und Release ist die Brache, die (in der letzten Version) zu Kunden ausgeliefert wurde. Da trete noch Fehler auf, die müssen dann Möglichst schnell behoben werden. Um dann natürlich Möglichst schnell zum Kunden zu kommen.
Dann kannst (musst aber nicht) du für alle 3 ein Dev, Test und Release Environment haben. Klingt jetzt erst mal schlimmer als es ist. Es ist größten teils Automatisiert und meist sind es nur Kleinigkeiten die sich ändern wie z.B. die Datenbank (lässt sich gut Automatisieren, du muss zwischen Dev und Test Environment nur eine Variable ändern, damit da Verschiedene Datenbanken verwendet werden. (Ich erkläre es hier einfach mal an Hand der DB, ich denke das ist am leichtesten nach zu vollziehen. Es gibt aber auch noch andere Gründe)
Also erst mal das einfachere. Wie so brauche ich zwischen den Quellcode Branches unterschiedliche Environments. Nun meist haben neue Features, auch den bedarf nach neuen Datenbank Feldern. Oder Brauchen neue Tabellen. (Wie gesagt ich mach es jetzt mal über die DB schiene). Die Dev Branche kann dann nicht mit der DB von Main Funktionieren und Main nicht mehr mit Release.
Das das bisschen Kompliziertere (kein muss). Du (kann bei der Dev Enviorment auch jemand anders sein als du) kannst als Entwickler einfach nicht alles Testen, dafür gibt es ja auch die QS. Du möchtest dann möglichst bei den Daten mit denen du testet, die du als Problematisch ansiehst. Bei der QS sieht es da schon ein bisschen anders aus. Die möchten lieber Daten die näher an Realen System vom Kunden dran sind. Und zum Schluss ist da natürlich der Kunde, der hat reale Daten. Und selbst bei der (Quellcode) Dev Branche, kann es sein das man sich da Daten vom Kunden besorgt. Damit die Kunden auf der Messe das Gefühl haben sie „Arbeiten“ an einem Realem System.
Wie sieht da dein Arbeitsprozess aus. (Ich mach es einfach mal am Beispiel von der Release Branche, bei anderen Branchen kann ein Fehler auch einfache ein Änderungswunsch oder ein neues Feature sein und betrachtet nicht alle möglichen Optionen).
Du gehst hin und Behebst einen Fehler. Der Gemeldet wurde last bei dir die UnitTest laufen. Und Checkst die Änderungen ein, wo bei du den Checkin mit dem Fehler verknüpfst, so das man später sehen kann welcher Fehler damit verbunden ist. Der CI Build mit UnitTest wird gestartet und du bekommst automatisch ein Feedback, das es nicht nur auf deinen Rechner Funktioniert. Sondern auch auf dem „Dev Test System“. Nach dem du „alle“ (können auch nur die dringendsten sein) Fehler behoben haste. Sagst du Bescheid (kann auch Automatisch passieren). Wird ein Build erzeugt, der (dessen Artefakt) Automatisch in die „Dev Envirorment“ geschoben wird. (Hier werden dann teilweise, noch Automatisch Integartionstest und Coded UI Test ausgeführt). Der Verantwortlich (kannst auch du sein) das die Software (das Artefakt), den Qualitätsansprüchen genügt. (Je nach Vorgabe kann man da auch noch ein paar Manuelle Test machen Und gibt dann frei das (Artefakt) es in der „Test Environment“ landet. (Was größtenteils Automatisch passiert). In der QS wiederholt es sich dann mit dem Testen und der Freigabe. (Nur die haben halt ein anderes Environment) und dann geht es weiter mit dem Release.
Für mich ist der Punkt, das ich das Vorgehen durchaus für sinnvoll halte. Und das was bisher möglich ist möglichst Automatisiert wurde.
Ja man muss es einrichten und es ist auch mit einem gewissen Aufwand verbunden. Danach muss man aber meist einfach nur ein paar Variablen ändern.
p.s.
Ja es ist schlampig geschrieben und ich hab nur die Aus meiner Sicht wichtigen Punkte angesprochen.
Mit RDP scheint es noch Probleme zu geben.
Zitat:"Für Anwender, die auf Remote-Desktop-Verbindungen angewiesen sind, heißt es daher zur Zeit noch: Finger weg von Version 1809. Ein Workaround eines Redditors besteht darin, die mstsc.exe aus einer 1803er-Windows-Installation zu verwenden."