Suchergebnisse

egal was du vorhast - nenne keine selbstgecodete Klasse ExtensionAttribute. Es gibt bereits eine Klasse dieses Namens, und die ist eminent wichtig. Wenn du gleich namige eigene Klassen schaffst, schaffst du damit erhebliche Verwirrung und schwer zu debuggendes Fehlverhalten.

Im gegenteil: Grad weil du sie so nennst, werden Extension-Methods anschließend nicht mehr funktionieren, wie eiglich vorgesehen.

Dann ist bei dir wohl auf eine entscheidende Dll nicht richtig verwiesen. Ich jdfs. attributiere meine Extension-Methods immer mit dem ExtensionAttribute-Attribut, was es schon gibt. Kannst ja mal dieses Sample-Projekt ausprobieren: Extensions und mehr.

ups- sorry - hatte nicht genau genug gelesen, dass du ja die ganze Zeit von FW2.0 redest - wäre nützlich gewesen, du hättest deinen Thread entsprechend getaggt. Jo, dann weiß ich auch nicht mehr als thefiloe: Eine Dll erstellt man durch Kompilieren - in deutschen VisualStudios gibts dafür "Erstellen"-MenuItems. Vlt. musst du in den projekteigenschaften den Ausgabetyp als "ClassLibrary" festlegen - falls du noch nicht hast.

Du kannst dein Werk ja mal zippen und anhängen, und ich guck mal rein.

Ich kann so kein Fehlverhalten feststellen. Hast du nicht eine Solution, wo diese Dll eingebunden ist, und die dann was versucht, was dann nicht funktioniert?

Die eingebundene Dll fehlt - das kann doch nicht so schwierig sein, einen Zipp zu erstellen, der das Fehlverhalten nachvollziehbar macht, ohne dass ich da selbst iwelche Veranstaltungen veranstalten muss, von denen ich nicht weiß, ob du sie in gleicher Weise veranstaltetest. Empfehlung: Zippe die ganze Solution , nicht nur einzelne Projekte, die ich dann selbst wieder zu einer Solution zusammenzusetzen habe.

Ich weiß, aber danach frug ich ja gar nicht. Ich frug nach einen Zip, der das Fehlverhalten in einer vernünftigen Weise reproduziert.

ich möchte einfach den zip entpacken können, und die darin enthaltene .sln-Datei per Doppelklick im Visualstudio öffnen könnnen, sodass mir eine Solution geöffnet ist, wie sie auch dir vorliegt, wo 2 Projekte in einer Solution zusammengebunden sind. Ich will das nicht selbst zusammenbinden müssen, weil dann weiß ich nur, wie ich das zusammengebunden hab, und nicht, wie du das zusammengebunden hast. Ausserdem sollte es in deim Interesse liegen, deine Frage nachvollziehbar zu machen, das erhöht di…

Ah - Also der Fehler war einfach, dass du das Extension-Modul nicht public gemacht hast. Und noch eine generelle dringende Empfehlung: Visual Studio - Empfohlene Einstellungen

Einen Namespace würde ich aber dennoch empfehlen. Meine Extensions ordne ich immer den Namespaces zu, deren Objekte extended werden, also hier liegt eine String-Extension vor, die würde ich demnach System zuordnen. Meine Empfehlung geht übrigens über das Option Strict On hinaus: Schmeiss auch den MVB-Namespace raus. Und mach das vor allem für das VisualStudio als ganzes, dann kommt sowas vergessenes nicht immer wieder vor (also ich hör das jdfs. ziemlich oft, das mit dem "Vergessen" )