Forenbeiträge von Peter Bucher Ingesamt 5.941 Beiträge
Salute Tott
Nö, das macht kein Spass 😉.
Ein Tipp, nimm das aktuelle MSDN V-Server Angebot von Qualityhosting.
Super günstig und genau was ein Webentwickler braucht 😃
Ich habe einen Server bei denen und bin super zufrieden.
Gruss Peter
Salute Tott666
Genau, Hostheadereintrag für deine Seiten im IIS und die DNS-Einträge müssen natürlich auch die IP des Webservers (V-Servers) lauten, dann passts.
Gruss Peter
Salute konto22
Auch wenn du es nicht hören willst: PlaceHolder.
Diese kannst du per Code oder aber auch deklerativ benutzen.
Das Panels als Tables gerendert werden, höre ich das erste Mal, müsste ich mal testen.
Wenn du nichts formatieren musst, gibt es auch keinen Grund etwas zu rendern, von daher würde ich ein PlaceHolder-Control nehmen.
Gruss Peter
Salute xpHelper
Ich verstehe auch nicht genau, was du vorhast.
Den Querystring (Also den ID Parameter) kannst du per Request.QueryString[<Key>] auslesen.
Gruss Peter
Salute xpHelper
Pro Contentseite einen anderen Text?
Dann siehe:
Ansonsten kannst du doch das Label direkt ansprechen?
Gruss Peter
Hallo zusammen
Auf jeden Fall die erste Variante.
Gruss Peter
Salute zusammen
haargel, du könntest ja eine Queue am Server nutzen, der die Aufträge so abarbeitet, das die Auslastung auf dem Server ertragbar sind, zu jeder Zeit.
Für MAC-Adresse, irgendwelche Hardware IDs brauchst du zwingend etwas clientseitiges, dass das ausliest.
Gruss Peter
Salute Cheeesi
Sowas gabs früher in Visual Studio 2003 noch, dort konnte man zwischen zwei verschiedenen Layouttypen wählen.
Das Ergebnis war, das die Controls bzw. die Html-Elemente absolut per Inline CSS positioniert war, was in den meisten Fällen unglücklich ist.
Das Fazit ist, dass du deine Html-Elemente selber per CSS formatierst.
Dazu auch:
Grus Peter
Salute EnterTheMatrix
Ich glaube du hast die Erklärungen noch nicht verstanden bzw. missverstanden.
Deine Frage war: "Warum Indexer?"
Diese Frage wurde beantwortet, hier aber noch meine Ansicht:
Indexer gibt es aus dem Grund, das über den Index auf was zugreifen kann, ohne eine Methode zu benutzen.
Dann meintest du, wieso man nicht List<T> nehmen könnte. Naja, kann man, aber -wie schon geschrieben - geht das nur, weil List<T> die Indexer benutzt.
Ich hatte das Gefühl das deine Frage dann umschwenkte auf "Lieber einen Indexer nehmen, oder eine List<T>?".
Naja, kommt darauf an was du willst. Da der Indexer die eigentliche Datenquelle nebenbei noch wegabstrahiert, es also egal ist was darunter ist, ist der Indexer natürlich geeignet, falls du nur Indexzugriff brauchst.
Intern hingegen ist eine List<T> natürlich praktischer, weil sie mehr bietet.
Wie herbivore schon angemerkt hat, sollte List<T> nicht öffentlich verwendet werden, da sie unter anderem nicht erweiterbar ist, siehe auch:
- http://www.aspnetzone.de/blogs/peterbucher/archive/2009/11/19/wann-ienumerable-nutzen-wann-icollection-und-wieso-berhaupt-ilist.aspx (Und die Links darin).
Gruss Peter
Salute Stipo
Halt, Stop!
Deshalb dachte ich mir, das ich in der global.asax in Session_Start() dies einmal auslesen lasse aus der DB und dann im ApplicationState speichere.
Wieso Session_Start und wieso hier den ApplicationState?
Du hast zwei verschiedene Arten von Daten, zuerst mal die Applikationsbezogenen (Metadaten, etc...) und zusätzlich die Benutzerbezogenen wie beispielsweise das ausgewählte Theme oder andere Einstellungen.
Diese musst du im korrekten Kontext speichern und auch Laden.
Du hast drei Aufgaben:
- Daten schreiben
- Daten auslesen
- Daten cachen
Diese Aufgaben kannst du nicht für alle Daten gleich aufbauen.
Speichern kannst du alles in der Datenbank, das ist kein Problem.
Für die Benutzerdaten musst du allerdings noch eine Zuordnung (Bspw. BenuzterID) zum aktuellen Benutzer hinterlegen.
Cachen kannst du alle Daten auf die gleiche Weise, wenn es denn nötig ist.
Die Benuzterdaten lädst du, sobald du die Zuordnungsdaten zur Verfügung hast (BenutzerID), das wird meistens bei Session_Start noch nicht der Fall sein. Also eher bei einer expliziten Anmeldung in deiner Anwendung, dem Login.
Die Anwendungsdaten kannst du bei Application_Start aus der Datenbank in den Cache laden.
Die Daten änderst du einfach in der Datenbank und löst eine Aktualisierung des Caches bzw. der Session aus.
Gruss Peter
Hallo Florian
In meinen Augen gilt hier - wie fast immer, es kommt drauf an. Wenn du zu 100%(!!) sicher bist dass sich die Klasse nie ändert finde ich es valide keinen zusätzlichen Test aufzubauen. Beachten 100% heißt 100%, nicht "99% sicher" (wie du geschrieben hast).
Der Witz ist - und das wollte ich auch rüberbringen - das du nie sagen kannst "Das ändert sich nie".
Selbst wenn du es sagen könntest, kannst du dich evt. später nicht mehr daran erinnern, es ändern die Umgebungsfaktoren oder aber ein anderer aus dem Team schraubt daran rum.
Gruss Peter
Salute winSharp93
Sorry, mein Schweigen war natürlich nicht gewollt, ich war einfach zu eingespannt.
Man kann zwar sagen "Das wird sich nie ändern, die Anforderung bleibt gleich, etc...", nur sollte man das nicht, denn man kann es nicht wissen! Nie!
Aus was schließt du diese Einstellung meinerseits?
Was ich nur gesagt habe: Wenn sich die Anforderungen ändern, dann wird auch OddCounter sich ändern müssen.
:
Ich habe das nur einem deiner Sätze entnommen und wollte damit anmerken, das man nie sicher sein kann.
Das liegt am Beispiel; in Wahrheit ist es so, dass der Analyzer nicht generisch, sondern doch etwas spezieller ist. Er dient auch schon als eine Strategie für eine andere Klasse; besser wäre vielleicht OddAnalyzer - andere Analyzer würden z.B. die Nummern nicht sequentiell durchlaufen, sondern z.B. nur jede 3.
Es gäbe also bisher maximal eine denkbare Strategie. Daher jetzt schon anzufangen, diese zu entkapseln, halte ich für falsch (im Stile von YAGNI).
:
Okay, alles klar, einverstanden.
Oder anders gesagt: Ich brauche das Interface doch gar nicht.
Dann habe ich das falsch aufgefasst.
Irgendwie habe ich das Gefühl dass du mit Blick auf die öffentliche API testest.
Wenn du mit öffentliche API die der einzelnen Klasse meinst:
Ja - mache ich. Internals von Klassen teste ich nicht - das ist ja Teil der Implementierung. Private Member teste ich generell nicht.
Sollte ich das ändern?
Irgendwie habe ich das Gefühl dass du mit Blick auf die öffentliche API testest.
Wenn du mit öffentliche API die der einzelnen Klasse meinst:
Ja - mache ich. Internals von Klassen teste ich nicht - das ist ja Teil der Implementierung. Private Member teste ich generell nicht.
Sollte ich das ändern?
und....
Du musst hier ganz klar und strikt öffentliche API / Kapselung sowie "Was muss / soll ich testen" differenzieren, das hat keinen Zusammenhang, überhaupt keinen.
Jetzt bin ich aber verwirrt: Sinn von Unittesting ist doch, verschiedene Szenarien aufzustellen, unter denen die öffentliche API (der Klasse) gewisse Resultate liefern?!?
Was soll ich denn sonst testen? 👶
Es geht ja darum eine möglichst hohe Testabdeckung zu gewährleisten, ob jetzt etwas nicht sichtbar ist bzw. einfach so Interna ist, spielt dabei keine Rolle. Das einzige Problem dabei ist der Aufwand sowas zu testen.
Ich meine, wenn ich eine private Methode habe, diese jedoch einen wesentlich Algorithmus enthält der funktionieren muss, damit meine Anwendung richtig tut, will ich diese auch testen und ich sollte sie auch testen.
Es ist also eine Abwägung zwischen Wichtigkeit und Aufwand. Dafür gibt es dann mehrere Möglichkeiten, bspw. das Attribut "InternalsVisibleTo" und die privaten Members auf internal setzen, oder die Codegenerierung von Visual Studio für private Members.
Man sollte sich m.E. also nicht generell eine Grenze ziehen und das mit Sicht auf die öffentliche API sehen, sondern je nach Fall abschätzen, wie wichtig es ist das zu testen und wieviel Aufwand es macht.
Gruss Peter
Salute Jdam
Wenn für dich das ein Killerargument ist, kannst du dich doch einfach in Silverlight einarbeiten. Für so eine Aufgabe wird das nicht viel Zeit kosten.
Die Theorie hast du ja.
Gruss Peter
Salute ahiram
Na dann schau dir den Teil mit dem Ausloggen an, daran wirds liegen.
So ein Verhalten kommt nicht automatisch.
Gruss Peter
Salute zusammen
Ich habs herbivore nachgemacht und finde meine Beiträge unter "4 4 W o r t e" 😃
Klappt bestens.
Gruss Peter
Salute dragon
Die Suche ist allgemein relativ schwach, wenn es darum geht etwas spezifisches zum Vorschein zu bringen.
Ich verlasse mich da auf Stichwörter oder Eigenheiten, an die ich mich erinnern kann.
Sogesehen kann ein Rechtschreibefehler - wenn man ihn dann noch weiss - sogar beim Auffinden nützlich sein 😉.
Einen Hinweis an Moderatoren mit der Bitte zur Korrektur finde ich sinnvoll, vorallem für die Allgemeinheit, die nicht mit falschen Stichwörtern sucht.
Für gewisse Themen, bei denen ich mit der Suchmaschine überhaupt keinen Erfolg habe, nutze ich Google um myCSharp zu durchsuchen, meist mit grossem Erfolg.
Probleme machen doch kreativ, nicht? 😃
Gruss Peter
Salute Bernd
RamDisks waren früher sehr interessant, aber Heute mit der Verfügbarkeit von SSDs sehe ich da nicht mehr viel Relevanz, ausser für spezielle Anwendungen.
Ich meine, VS auf einer Ramdisk oder das ganze Betriebssytem auf einer "grossen" Ramdisk aka SSD, was hört sich besser an? 😃
Dann kannst du auch getrost alle Anwendungsfälle einer Ramdisk vergessen, da du sowieso alles im RAM hast 😃
Gruss Peter
Salute Florian
Das sehe ich genau so 😃.
Gruss Peter
Salute Florian
Dein ersteres Argument mit dem Erzeugen des Commands sehe ich ein.
Jedoch verstehe ich nicht, für was du eine Abstraktion für DbParameterCollection benötigst, das ist doch selber schon eine Abstraktion, eine Basisklasse und überhaupt nicht an irgendwelche konkrete Provider gebunden?
Gruss Peter
Salute RipperMac
Ich nehme an ASP.NET?
Dann schau mal hier:
Und ein lauffähiges, minimales Beispiel:
Gruss Peter
Hallo zusammen
Ich halte es genau wie Golo und gehe nach der Empfehlung / Konvention von Microsoft vor: Jeder Typ in eine einzelne Datei.
Gruss Peter
Salute joola
Ich weiss es auch nicht, dazu musst du mir erstmal erklären was du mit:
Nun will ich in der einen Klassen innerhalb einer for Schleife die andere Klasse aufrufen.
meinst und was du daran nicht verstehst.
Gruss Peter
Salute winSharp93
Gute Fragen 😃.
Im ersten Moment erschien mir das auch irgendwie paradox, im zweiten Moment allerdings fiel mir auf, das du nicht ganz üblich vorgegangen bist.
Du wendest zwar das SRP Prinzip an, jedoch kommt mir das so zwanghaft vor.
Man kann zwar sagen "Das wird sich nie ändern, die Anforderung bleibt gleich, etc...", nur sollte man das nicht, denn man kann es nicht wissen! Nie!
Also, wieso entwickelst du nicht generell gegen Interfaces?
Damit hättest du die meisten Probleme schon erschlagen, bzw. wäre die gar nicht wirklich aufgetreten.
Der Analyzer an sich gäbs eher nur einmal, jedoch würde ich 1. die Methode benennen "Was macht Analyze?" und dann ggf. die Analysierungsstrategy auslagern - mit dem Strategy Pattern - und dann hättest du bspw. eine OddAnalizerStrategy, etc...
Passt jetzt zwar nicht ganz, da deine Signatur der Analyze Methode zu wenig generell ist.
Ich würde aber so vorgehen, denn dann erschlägst du m.E. alle Probleme von selber.
Irgendwie habe ich das Gefühl dass du mit Blick auf die öffentliche API testest.
Du musst hier ganz klar und strikt öffentliche API / Kapselung sowie "Was muss / soll ich testen" differenzieren, das hat keinen Zusammenhang, überhaupt keinen.
Gruss Peter
Salute winSharp93
Ich kann mich grösstenteils an Golo anschliessen.
TDD ist nicht einfach, vorallem am Anfang nicht.
Auf das genau gleiche Problem bin ich bei meinem ersten TDD-Projekt auch gestossen, nur habe ich das erst gegen den Schluss rausgefunden.
Streng genommen sind das wirklich Integrationstests, da du ja ein einzelnes Unit unten durch mittestest.
Nun, wirklich wichtig finde ich vorallem die Vor- und Nachteile die man damit hat.
Du hast weniger Arbeit und es besteht ein Integrationstest, das ist soweit ganz gut. (Obwohl ich da die Arbeitszeit auch eher als zweitrangig betrachte, wenn ein qualitativ hochwertiges Produkt auf dem Spiel steht).
Der Nachteil kommt eigentlich erst dann zum Vorschein, wenn Tests fehlschlagen.
Du weisst dann zwar, okay, der Integrationstest ist fehlgeschlagen. Und irgendwie weisst du auch (hoffentlich), das innerhalb dieses Integrationstests irgendwie ein Unit mitgetestet wird.
Wenn du das nicht weisst, ist es blöder.
Der Punkt ist, das du beim Fehlschlagen des Integrationstest, nicht sagen kannst, an welchem Unit es liegt. Wenn du jetzt dieses Unit - deine Hilfklasse - dediziert testest, hast du diesen Test der fehlgeschlagen ist und bist näher am Fehler dran.
Integrationstests sind nicht böse, es ist sogar gut, wenn man einen hat, jedoch birgen sie genau diesen Nachteil.
Zusätzlich hast du natürlich nicht so eine hohe Testabdeckung, wenn du einfach Units weglässt.
Gruss Peter
Salute MarsStein
Wieso benutzt du "ref" bei einem Referenztypen?
Ist doch an der Stelle völlig OK, es wird dem Übergabeparameter ja innerhalb der Methode ein neues Objekt zugewiesen, das auch außerhalb weiterverwendet werden soll??
Ja du hast Recht, war wohl nächtliche Blindheit 😃
Gruss Peter
Salute ChrDressler
Du willst also eine Methode mit folgender Signatur:
private ObservableCollection<T> LoadEntitiesOfType(Type typeOfEntity);
Wenn du sagst das der Typ variabel gehalten wird?
Macht aber keinen Sinn, da du sowieso das generische Typargument T angeben musst, ausser du gibst object zurück, irgendwann brauchst du aber einen Cast auf den konkreten Typ.
Ausserdem ist es ja kein Problem alles bis zu einem gewissen Grad generisch zu halten, bis zum eigentlichen Clientcode, also dem Code der die Methode benutzt.
Du kannst den T Typen einfach weiterreichen, ich gehe davon aus das deine Interfaces generischer Herkunft sind, dann hast du auch keine mit dessen Aufrufen.
Sowas:
private ObservableCollection<T> LoadEntities<T>(IConnectionConfiguration connectionConfiguration)
{
IEntityLoader<T> entityLoader = new EntityLoader<T>(connectionConfiguration);
return new ObservableCollection<Employee>(entityLoader.LoadEntities());
}
Articles.App.Connection ist ein Interface, ein String?
@Schamanese
Wieso benutzt du "ref" bei einem Referenztypen?
Siehe:
Gruss Peter
Hallo schillerdeluxe
wo diese positioniert sein soll?
Bitte drücke dich ein wenig detailierter aus.
Wo auf der Webseite?
Oder wo auf deinem Bild ein anderes Bild positioniert werden soll?
Zu ersterem hast du die Antwort bereits.
Gruss Peter
Salute Christian
Das wird uns der liebe Fragen gleich sagen, ich weiss es auch nicht sicher.
Ist nur meine Einschätzung da Web Technologien und ASP.NET sowie Response.OutputStream...
Gruss Peter
Salute schillerdeluxe
Prinzipiell:
Dann machst du nichts anderes als das du das Bild selber per CSS positionierst.
Oder meinst du was anderes?
Gruss Peter
Salute schillerdeluxe
Wie willst du was schieben?
Gruss Peter
Salute cyanide
Ich würde die Klasse auch anders benennen und wenn möglich von einer generischen Basisklasse ableiten, bswp. Collection<T> oder List<T>.
Für was ist diese Property?
Irgendwie hört sich das für mich nach einer Singleton Implementation an, da würde doch Instance oder Current besser passen, als Commands?
Was würde es denn bringen, die Klasse in einen anderen Namespace zu packen?
Ich würde das ja als "Problemverlagerung" abzun 😉
Gruss Peter
Salute Jack
Nein, aber wieso soll ich mir damit die Vollständigkeit meiner API Kommentare versauen? 😉
Gruss Peter
Salute zusammen
Das habe ich zwar schon einmal erwähnt, aber nochmal: Clean Code ist extra extrem um aufzurütteln, man soll nicht alles für bare Münzen nehmen.
Bspw. sind Xml Docs (Gibts in Java auch) explizit von der Regel ausgeschlossen das Kommentare böse sind. Also sollte auch nicht darüber diskutiert werden.
Zum Selbstreden: Nunja, selbstredenden Code ist ja gut und schön. Allerdings habe ich noch nie eine wirklich selbstredende API gesehen - und genau dafür sind diese Xml Docs für Beispiele gedacht.
@Jack
Deine Schlussfolgerung "Dann kann man die Kommentare doch gleich weglassen" ist schon mal ganz böse 😃.
Grundsätzlich sollte nicht das offensichtliche kommentiert werden, das ist einleuchtend.
Allerdings handelt es sich hier wieder um Xml Docs. Dafür bekommst du Intellisense und API Dokumentation frei Haus.
Soll die leer sein oder soll dort das stehen, was du im Kommentar hast?
Ich würde mich für zweiteres entscheiden.
Gruss Peter
Salute zusammen
Ich halte es fast wie Golo, alles ausser privaten Variablen kommentieren.
Gruss Peter
Salute zusammen
Habe ich übersehen, so wird halt einfach implizit die ToString()-Methode des Typs aufgerufen.
Wenn die bspw. so implemtiert ist, ist der Fall klar:
public override ToString()
{
return "1234";
}
😉
Gruss Peter
Hoi math55
Mit deinem gezeigten Code sowie deinen Erklärungen ist das unmöglich.
Also entweder testest du falsch oder wir haben zuwenig Infos.
Gruss Peter
Hoi unconnected
Ich rate natürlich nicht generell davon ab, sondern nur in einem solchen Fall.
Du sollst keinen Code direkt in deiner ASPX-Seite haben, ausser eben DataBinding Ausdrücke.
Und du "missbrauchst" hier die Databinding-Syntax um eine Codeausgabe auf die Seite zu bringen, was IMHO nicht richtig ist.
Nimmt dazu - wie schon erwähnt - lieber ein Control das du platzierst, und sei es nur ein PlaceHolder oder LiteralControl.
Dann kannst du im Codebehind hingehen und dieses ansprechen und füllen.
Gruss Peter
Salute unconnected
Das liegt daran, das du einen Databinding Ausdruck verwendest, das solltest du in diesem Kontext nicht tun.
Wenn du this.DataBind() aufrufst, sollte es klappen.
Mach das aber nicht, sondern setze ein Label / Platzhalter in die Seite und fülle diese vom Codebehind aus mit Inhalt.
Gruss Peter
Salute Rodney
Dafür brauchst du wohl harte Referenzen auf die DLLs, sonst kennt VS die zur Designzeit nicht.
Dann ist jedoch der Vorteil von IoC auch wieder praktisch weg, nicht ganz, aber schon minimiert.
Gruss Peter
Hallo zusammen
Die Reaktionszeit von Windows ist mit einer SSD um Welten besser, das Arbeiten viel angenehmer.
Es ist also nicht nur der Build, wofür sich eine SSD lohnt.
Einmal SSD, immer SSD 😃
Gruss Peter
Salute dN!3L
Die Kompilierungszeit hat sich bei mir nach der SSD drastisch verbessert, um mehr als das Doppelte.
Gruss Peter
Salute zusammen
Ich habe auch schon seit längerem eine SSD in meinem Rechner drin, der Geschwindigkeitszuwachs ist enorm.
Schlussendlich ist die Festplatte auf praktisch allen Maschinen für alle Anwendungen die Bremse.
OS mässig fahre ich seit Vista nur noch 64bit, so kann auch der gesamte Arbeitsspeicher addressiert werden und das System läuft IMHO auch schneller.
Gruss Peter
Salute Yheeky
Du musst den Typen vollqualifiziert angeben, d.h. auch noch den Assemblynamen dazu.
Wenn du ein Web Application Project hast, ist es der Name der ASP.NET Anwendung.
Also bspw.:
type="MyProject.RoleProvider, MyProject"
Gruss Peter
Hallo Golo
Okay, mit den ersten beiden Sätzen hast du vollkommen Recht, habe ich übersehen 😃.
Jetzt kommt ein ganz doofes Beispiel, weil mir nichts besseres einfällt:
Es gibt ja Hybrid-Autos, die haben auch zwei (oder mehr) verschiedene Konzepte für die gleiche Aufgabe. Und dadurch verschmelzen die Vor- und Nachteile was sich schlussendlich positiv auswirkt.
Ich meine, die Frage an dich wäre ja:
Was genau stört dich daran zwei Konzepte kombiniert anzuwenden?
Und wenn jetzt eine Anwendung, bspw. ASP.NET MVC komplett mit DI funktioniert, ausser 1, 2 Calls auf den SL brauchen, weil in (Action)-Attribute nichts per DI injected werden kann?
Soll ich dann alles per SL machen, weil es sonst 2 verschiedene Konzepte sind?
Ich finde die Diskussion spannend, aber irgendwie fällt es mir schwer hier integral zu denken. Denn ich verstehe deinen Standpunkt irgendwie aber irgendwie auch wieder nicht.
Ich meine, irgendwie sehe ich den Nachteil schon, wenn man zwei Konzepte für die gleiche Aufgabe hernimmt, meistens bringt das nichts. Aber ich finde es nicht gut, auf die Vorteile des anderen Konzeptes zu verzichten.
Gruss Peter
Hallo Golo
[...]
Das Registrieren muss ich so oder so machen. Ob ich einen Konstruktor schreibe mit entsprechender Zuweisung oder den Aufruf des SLs an der entsprechenden Stelle einfüge, gibt sich auch nicht viel.
Was ist der Vorteil, wenn ich DI zusätzlich nehme?
Es kommt auf den Anwendungsfall an.
Wenn alles mit DI erledigt werden kann und das soweit passt, nutze ich das auch und brauche mich nicht händisch darum kümmern.
Zusätzlich kann sich der Container auch noch um den Lebenszyklus der angeforderten Instanz kümmern, ohne das ich da gross Handstände machen muss.
Und wenn du DI und SL kombinierst, hast du keine Nachteile mehr und die Vorteile beider Anwendungen.
Ich habe kein Problem damit, zwei verschiedene Konzepte anzuwenden, wenn ich sie verstanden habe.
So als Beispiel: Du verwendest ja auch prozedurale und objektorientierte Konzepte, die sich super ergänzen, oder?
Gruss Peter
Salute zusammen
Ich versuche jetzt nicht eine Lösung auf Golos Beispiel zu finden, da es "so" keine gibt. Höchstens könnte man sich fragen, ob die Umsetzung so wie sie ist, überhaupt ok ist, und wirklich lokale Variablen benötigt werden.
Zum anderen sehe ich es auch so, das sich DI und SL ergänzen, und zwar beidseitig.
Dein Argument - Golo - ein neues Konzept einzuführen, zieht nicht, finde ich.
Denn, wo du SL benötigst, nutzt du dieses. Wenn du eine Instanz per SL ziehst, die ihrerseits wiederum andere Abhängigkeiten hat, die aber nicht dynamisch sind, passiert es ja vollautomatisch, wenn du konfiguriert hast.
Du musst da also nichts überlegen und auch nicht zwei Konzepte "einbringen", die bestehen ja schon for free.
Gruss Peter
Hoi Golo
Das ist wirklich ein Punkt und interessant.
Jedoch frage ich mich, wo man diesen Anwendungsfall benötigt.
Ehrlich gesagt fällt mir da überhaupt keinen ein, in praktisch allen Fällen ist es ja so, oder sogar besser wenn die Abhängigkeit an die Instanz gebunden ist.
Gruss Peter
Hallo David
2.0 und 3.5 ist dasselbe im IIS, wichtig ist das du in der web.config den neuen Bereich nutzt, dort kannst du dann den 3.5 Kompiler hinterlegen.
"funktioniert nicht" gibts nicht 😉
Gruss Peter
Hallo gonzales36
Siehe hierzu:
Gruss Peter
Hallo gaonzales36
Nein, mit dem UpdatePanel durchläufst du immer den gesamten Page-Lifecycle.
Abgesehen davon ist ein "Update" des UpdatePanels sowieso immer ein neuer Request und alles fängt bei 0 an, wie im Blogpost beschrieben.
Gruss Peter