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.
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?
Zitat von GrilleGsutav
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.
(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.
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.
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.
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."
Ich finde das Lizenssystem vom TFS (zur Vereinfachung) auch ein bisschen unübersichtlich. Aber Grundlegend ist schon richtig was du sagst, Nutzer die das System nur als Informationsquelle brauchen, brauchen keine Liezens. Man kann aber auch ohne CAL zu brauch noch mehr machen. Da solltest du dir aber dann mal genau die Lizenzen anschauen.
Auch ohne Cloud hat der TFS ein Webe Webseite, die im allgemeinen für den zugriff (auf die Informationen) genutzt wird. Es gibt aber auch noch unterschiedliche Tool mit denen man zugreifen kann.
einmal kannst du hingehen und sagen es wird eine Zahl (N) angegeben bis zu der du die Werte von 1 in Kreise aufteilen möchtest und dann brauchst du noch die Anzahl der Kreise (K). N/K ergibt dann die Anzahl von Zahlen Pro Kreis (AK), hier brauchst du einen Teiler ohne Rest. Dann Teilst du 360° durch AK und bekommst den Winkel im den du immer wider Verschieben musst. Schau dir mal die Funktion von Mars Stein an)
[Edit]
Für den Nächsten Kreis fängst du dann natürlich ein Stück Höher an zu Zeichnen.
Es ist in dem Rahmen nicht unbedingt der „Ist Zustand“ sondern der „Soll Zustand“.
Aber ich denke wenn man sich die Beiträge/Personen anschaut, die eine hohe Reputation (Bewertung) haben. Geht es nicht nur darum, einfach ein Problem zu lösen, weshalb sich viele Leute an Stackoverflow (Exchange) wenden. Sonden zu erklären was dahinter Steckt. Was teilweise deutlich tiefer geht als Artikel die man auf Wikipedia finden kann.
z.B. Macht meines erachten Eric Lippert da wirklich gute Arbeit.
Wenn ich es richtig im Kopf habe Beschränkt TDD wie es sich Kent Beck vorgestellt hat auf „reine Unit Test“. Integrationstest und Coded UI Tests sind da nicht wirklich vorgesehen. Und wenn der Code nicht Testbar ist, können sie dich auf Fehler bei der Software Architektur aufmerksam machen.
„Reine Unit Test“ sind im allgemeinen sehr sinnvoll, da sie im Endeffekt kosten Sparen. Dazu gibt es auch eine Studie die bei IBM und Microsoft durchgeführt wurden (Bin grade zu faul das Raus zu suchen, sollte sich aber über google finden lassen.). Sie sind relative einfach geschrieben und der nutzen ist relative groß.
Integrationstests und Coded UI Test, sind da schon ein anderer Punkt. Sie sind je nach Gegebenheit relative aufwändig. Und der nutzen ist meist nicht mehr so groß wie bei Unit Tests. Teils Testen sie nochmal was die Unit Test schon abdecken. Hier muss man einfach zwischen Kosten und nutzen Abwiegen.
Das „Driven“ in TDD, kann schon mal bei manchen Programmieren für Probleme sorgen. Da es ihnen schwer Fällt, erst den Test zu Schreiben und dann den eigentlichen Code. Meines Erachtens ist es da auch nicht sinnvoll, die Leute dazu zu Zwingen. Sondern es vollkommen OK, wenn sie erst den Code schreiben und dann die Tests. (Wenn es dann Probleme gibt die Test zu schreiben, müssen sie halt dann ein Refactoring machen.)
Ich denke hier sollte man das Eigentliche Ziel nicht aus den Augen verlieren. Man schreibt Tests, weil sie die Produktivität steigern. Und es deutlich günstiger ist, wenn ich den Fehler bei mir finde, als wenn mir ein Kunde von einem Fehler berichtet und ich dann erst auf seinen System den Fehler nachvollziehen muss.
Was mich eigentlich zu einen Anderen Punkt führt (und vielleicht ein anders Thema sind, im Zweifel bitte abtrennen). Nicht nur Unit Test sind ein Schlagwort, sondern Natürlich auch Agile Software Entwicklung mit Scrum oder Kanaban (Halte ich Persönlich für sehr gut und ich denke man sollte schauen, sie soweit wie Möglich Umsätzen). Was dabei meines Erachtens oft übersehen wird. Ist das man mit Menschen zusammen Arbeitet und es im Unternehmen, existierende Strukturen gibt. Und das eigentliche Ziel es nicht, nicht ist Scrum oder sonst was umzusetzen. Sondern Produktiver zu Arbeiten. Was eigentlich auch Grundlage des Agilen Manifests sind.
Scrum usw. können einen dabei Gute Hilfestellung leisten. Ich denke aber was wichtiger ist Individuell auf die Menschen und das Unternehme einzugehen.
Bin eigentlich noch dabei, eine Ergänzung zu meinen 1. Beitrag zu schreiben und habe eigentlich keine Lust mit Abt zu diskutier. (Ich werde es auch nicht machen.)
Aber Nein ich kann kein Interface mit Unit Tests testen (auch nicht Interface*), sondern nur Konkrete Implementierungen. Ein Interface MakeSound, was für eine Implementierung Katze „Miau“ und für einen Hund „Wuff“ zurück gibt. Kann nicht als Interface getestet werden. Es gibt natürlich Fälle in denen ich die Gleichen Werte in eine Methode gebe und dann die Gleiche Rückgabe erwarte. Grundlegen sollten die Implementierung der Methoden was anders machen. Sonst bräuchte ich nicht die 2. Implementierung, der Methode. Und dann sollte ich sie Unterschiede Testen.
Interfaces sind dann Interessant, wenn ich sie durch Mocks (Ich ersetze die Konkrete Implementierung durch eine Klasse, die mir einen Vorgegebenen Wert zurück gibt) bei Integrationstests ersetze kann. Und so die Tests Vereinfachen kann. Um sie z.B. von einer DB abzukoppeln.
bei TDD schreibst du ja Test für Methoden die Public sind. Du kannst Teile des Codes natürlich auch in private Methoden auslagern. Das sollte in der Refactoring Phase passiert. Vereinfacht. Test schlägt Fehl -> Test bestanden -> Refactoring Test funktioniert immer noch. Nächster Test für die Methode.
Wenn es nötig ist kannst du die private Methode auch beim Refactoring in eine eigene Klasse auslagern und public machen. Deine Tests sollten immer noch Funktionieren und du kannst, dann wenn es nötig ist für die Methode Tests schreiben.
Änderungen sind ja eigentlich im Normalen Workflow schon vorgesehen. Du fängst ja möglich einfach an. Ich denke mal anstelle einer Zahl als String übergibst du "NULL" , "STring.Empty" oder eine andere ungültige Eingabe. Ich würde hier eine Exception erwarten. Dann kommt der nächste Test z.B. "1" ich würde erwarten. Das mir die Methode dann die Zahl zurück gibt. (Negative Test auf Max und Min nicht Vergessen). Und dann die Addition "5+3". Vielleicht brauchst du ja erst mal die Multiplikation nicht und musst sie erst Jahre später Implementieren. Dann schreibst du die neuen Test und implementierst die Änderungen. Die alten Test sollten in dem Fall noch weiter Funktionieren.
Es kann natürlich auch sein, das Änderungen alte Test brechen. Weil es so gewollt ist. Dann spricht nichts dagegen den Test auch zu ändern. Z.B. könnte "*" im String erst mal eine "Not Supported" Exception schmeißen. Was sich dann ändert, wenn es nach Änderungen doch funktionieren soll.
Der Punkt hier ist, das du drauf hingewiesen wird. Das sich was geändert hat und du dann zustimmst, das du die Änderung auch möchtest.
Und ja es wird manchmal als Nachteil Bezeichnet, das wenn man Breaking Changes macht. Noch den Aufwand hat etliche Tests anzupassen. Der Vorteil ist, es kann dir nicht aus Versehen geschehen.
poste doch bitte mal die Konkrete Fehlermeldung.
Ansonsten schau mal mit dem Debugger was in "ApiResponseStr" drinsteht. Und prüfe mal ob es mit der Klasse "APIResponse" übereinstimmt.
wie machst du nicht eine Abstrakte Generische Basis Klasse, die die Methode zum Abrufen der Daten Public anbietet. Und eine Protetec Methode anbietet, die überschrieben werden muss.
Jetzt mal frei und schnell unterschriebenen
abstract Service
{
protected abstract T GetSpezialFoo(ServiceClient client);
public T GetFoo()
{
// dazu Logging, Localisation, Errorhandling, response-Header-Auswertung - einmal implementiert, und richtig
using (var myClient = new TService()) {
IClientChannel chnl = GetChannelFromClient(myClient);
using (var scope = new OperationContextScope(chnl)) {
OperationContext.Current.OutgoingMessageProperties["Autentication"] = _AutenticationToken;
return GetSpezialFoo(myClient); // <-- Hier wird dann die in den Abgeleitetet Klassen Implementierte Methode aufgerufen.
}
}
}
}
(ist jetzt ein bisschen her und ich hab da jetzt nicht gegoogeld) aber wenn du nur short (-32.766 bis 32.767 sollte grob stimmen) hast du das 1. Bit (ganz links) für das Vorzeichen (0=+ / 1= ).
Bei ushort hast du nur positive Zahlen. Das 1. Bit wird hier für die Zahl verwendet. Das erste Bit stellt also Zahlen > 32.767 das.
Da bin ich mir jetzt nicht sicher aber 1111.1111.1111.1111 ist glaube ich bei short -1 und wird bei ushort als 65535 dargestellt. -2 sollte dann 1111.1111.1111.1110 sein und 65534.
Am besten selber noch mal nachlesen. Ich hoffe ich konnte grob wieder geben worum es geht.
Der 1. Asynchrone Aufruf dauert länger als alle 6 Synchronen Aufrufe zusammen.
Ich sehe hier absolut keinen Grund es Asynchron auszuführen.
Das hat nicht mit Bockig zu tun. Das sind Zahlen.
Ich hab da einen einfachen Grundsatz, halte dich an Standards und mache es so einfach wie Möglich. (Wenn Auszubildende den Code Verstehen hab ich gute Arbeit geleistet, senkt auch deutlich die Kosten von Software, da der Quellcode von den meisten Gefleht werden kann.)
Und wenn ich es komplizierter machen will, muss ich einfach einen Mehrwert belegen können.
Also wenn die CPU zu 100% ausgelastet ist bringt mir async auch nichts. Ich denke das eine Betrachtung von knappen System Ressourcen für eine Verallgemeinerung, nicht wirklich sinnvoll ist. Wenn es irgendwo einen Flaschenhals gibt muss ich natürlich schauen, das ich ihn bei meiner Programmierung berücksichtige. Aber das ist ein anderes Thema.
Auch wenn async mittlerweile leichter zu Programmieren ist, heißt es nicht das ich es überall Einsätzen soll.
Einmal entsteht durch den Thread wechsle eine Overhead statt. Wenn ich einfach 2 Zahlen addiere ist der Overhead größer als die eigentliche Operation. Grundlegend lohnt es sich also nicht Operationen auszulagern bei dehnen der Overhead größer ist als die eigentliche Operation.
Dann muss ich auch immer drauf achten das keine Raceconditions auftreten. Wenn das Programm noch in eine Datei schreibt. Kann ich keine Änderungen in der Datei speichern. Das muss ich abfangen. Zusätzlich brauch der User da auch ein Feedback wie der aktuelle Stand ist (z.B. Vorschritts anzeige).
Zusätzlich kommt kommt hinzu das async Funktionen meist auch schwerer zu Debuggen sind.
Ich persönlich halten den Ansatz für richtig asyc zu Benutzten wenn ich es muss. Aber nicht einfach weil ich es kann. (KISS, YAGNI).
Und jetzt weiß ich auch nicht. Langsam beschleicht mich das Gefühl, ich habe Etwas Wichtiges bei dem Thema übersehen und mein Ansatz ist komplett falsch.
Der Zentrale Punkt ist, wie es für den Benutzer herüber kommt. Wenn die Datei in 20ms gespeichert ist, brauchst du keine asynchrone Programmieren und solltest sie auch in den meisten Fällen Vermeiden (Es ist einfacher zu Programmieren).
Wenn das Speichern einer Datei 1 Minute dauert sollte man den Benutzer anzeigen, das was geschieht (Was komplizierter ist).
Ich finde gerade den Artikel nicht. Aber wenn ich es richtig im Kopf habe.
Werden Vorgänge < 100ms als "relative" flüssig Endfunden.
Von 100ms bis 200ms als "stockend".
Über 200ms als Hakend. (Es kommt da auch immer auf die Aktion an, wenn ich eine Maus bewege, möchte ich das sie sich direkt bewegt. Speicher ich eine Datei ist es Ok kurz zu warten.)