Erweterungsmethoden in DLL

danieljena · 11. Oktober 2015, 09:53

Guten Abend,
ich habe es mittlerweile geschafft innerhalb des NF 2.0 Erweiterungsmethoden zu erstellen.
Mit Hilfe von:
piers7.blogspot.de/2008/07/usi…thods-in-net-20-from.html
codeproject.com/Articles/261639/Extension-Methods-in-NET

So nun zur eigentlichen Frage:
Wie schaffe ich es, diese Erweiterungsmethoden in eine DLL zu packen um diese dann in mehreren Projekten nutzen zu können?

mfg
danieljena

thefiloe · 11. Oktober 2015, 09:59

Was ist das für ne Frage. So wie jeden anderen Code auch. Einfach als dll kompilieren.

danieljena · 11. Oktober 2015, 10:08

mhm, leider nicht hinbekommen ...
Hier mal der Code aus der geplanten DLL:

Quellcode

Imports System
Namespace System.Runtime.CompilerServices
<AttributeUsage(AttributeTargets.Method Or AttributeTargets.Assembly Or AttributeTargets.Class)> _
Public Class ExtensionAttribute
Inherits Attribute
End Class
Module ex
<System.Runtime.CompilerServices.Extension> _
Public Function GetFirstThreeCharacters(ByVal str As String) As String
If str.Length < 3 Then
Return str
Else
Return str.Substring(0, 3)
End If
End Function
End Module
End Namespace

wenn ich dann die erstellte DLL in ein Projekt einbinde und eine String-Variable deklariere, habe ich keinen Zugriff auf die Methode 'GetFirstThreeCharacters'.
Oder mache ich so was falsch, stimmt der Code überhaupt?
Wenn die Methode im gleichen Projekt liegt, in welchem auch der Aufruf geschehen soll, funktioniert es perfekt.

ErfinderDesRades · 11. Oktober 2015, 11:03

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.

danieljena · 11. Oktober 2015, 11:13

Diese Klasse muss ExtensionAttribute heißen, sonst kann keine Erweiterungsmethode mittels <System.Runtime.CompilerServices.Extension> definiert werden.

ErfinderDesRades · 11. Oktober 2015, 11:18

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

danieljena · 11. Oktober 2015, 11:24

Hast du es ausprobiert?
Wenn ich bei mir aus der Klasse ExtensionAttribute beispielsweise eine Klasse DllEx mache, dann wird bei den Erweiterungsmethoden (in diesem Falle:

<System.Runtime.CompilerServices.Extension> _
        Public Function GetFirstThreeCharacters(ByVal str As String) As String

) ein Fehler angezeigt!

ErfinderDesRades · 11. Oktober 2015, 11:31

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.

danieljena · 11. Oktober 2015, 11:34

Ja schon nur so wie du es schreibt würde es im NF 2 nicht funktionieren, da es Erweiterungsmethoden eig erst ab NF 3.5 gibt.

ErfinderDesRades · 11. Oktober 2015, 11:42

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.

danieljena · 11. Oktober 2015, 11:54

Wie ich eine DLL erstelle weiß ich ja.
Nur leider bekomm ich dann im Projekt, in welcher diese dann eingebunden ist, keine Auswahl der "neuen" Methoden.

Schön wäre es ja, da der Wartungsaufwand von diesen Methoden geringer ist, wenn sich diese an einem zentralen Ort befinden und nicht in mehreren Projekten.

ErfinderDesRades · 11. Oktober 2015, 11:57

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

danieljena · 11. Oktober 2015, 12:01

siehe Anhang

ErfinderDesRades · 11. Oktober 2015, 12:11

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?

tolio · 11. Oktober 2015, 12:51

also ich hab das ganze grad mal durchgetestet und es ergibt sich wie folgt:

man nehme beispielsweise folgenden code für die externe dll.

C#-Quellcode

namespace ExtensionTest
{
public static class Extensions
{
public static string ExtensionTestMethod(this string instr)
{
return "Extension";
}
}
}
namespace System.Runtime.CompilerServices
{
public class ExtensionAttribute : Attribute { }
}

und verwendet das ganze in einem anderen projekt nach hinzufügen der referenz und dem entsprechenden import zb so:

C#-Quellcode

static void Main(string[] args)
{
var str = "abc".ExtensionTestMethod();
}

bei mir waren alle fehlermeldungen vom visual studio eindeutig genug um das ganze schnell zum laufen zu bekommen.

jetzt natürlich noch die frage warum funktioniert das so?
extension methods sind ein compiler feature und kein framework feature. deswegen kann man wenn das attribute welches der compiler sucht einfach hinzufügen wenn man das ganze für ein niedrigeres framework compiliert.

wie sich das ganze mit dem vb compiler verhält hab ich jetzt um ehrlich zu sein keine lust zu testen, aber ich gehe stark davon aus das wenn man alles an ort und stelle packt das es auch dort funktioniert, ich vermute man muss lediglich das this löschen und das attribute hinzufügen, aber das wird bestimmt jemand rausfinden.

danieljena · 11. Oktober 2015, 14:07

so, hier nun auch noch eine Solution wo es nicht funktioniert.
In dieser wurde einfach die DLL, mit dem Code aus dem dritten Poste eingebunden und die neue Methode taucht nicht im IntelliSense einer String Variable auf.

ErfinderDesRades · 11. Oktober 2015, 14:16

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.

danieljena · 11. Oktober 2015, 14:25

Die eingebundene Dll fehlt

Den Code dazu habe ich doch bereits gepostet

ErfinderDesRades · 11. Oktober 2015, 14:29

Ich weiß, aber danach frug ich ja gar nicht.

Ich frug nach einen Zip, der das Fehlverhalten in einer vernünftigen Weise reproduziert.

danieljena · 11. Oktober 2015, 14:36

tut es das nicht?
Genau so habe ich es aber getestet.
Die DLLExtensions geschrieben und dann in die DLLExtensionsTest eingebunden.

Erweterungsmethoden in DLL

Erweterungsmethoden in DLL

Quellcode

C#-Quellcode

C#-Quellcode

Tags

4 Benutzer haben hier geschrieben