Original von Fabian
Du kannst nur das CurrentDirectory umstellen und die Dateien dann mit DllImport einbinden. Eine andere Möglichkeit, außer CodeDom, fällt mir auch nicht ein. Benutzt du nicht eine Bibliothek, die ich dir gebastelt habe mit der man dynamisch DLLs laden und entladen kann? 🤔
Ganz zu schweigen davon, dass CodeDOM dafür da ist um Source code zu erzeugen oder Source code zu kompilieren. Und zwar im Sinne von einer IDE, oder Scripting durch den User.
CodeDOM zu missbrauchen um dynamisch IL zu erzeugen ist doch total krank, dafür gibt es Reflection.Emit.
Für's einfach Laden geht auch das hier

Marshal.GetDelegateForFunctionPointer

Original von onlinegurke
@HansDampf:
...mit denen aber schwer umzugehen ist, da ist CodeDOM noch einfacher zu verstehen... Dynamische IL ist ja auch nichts, was ein Application Dev mal einfach so machen sollte.
CodeDOM ist dafür da Source Code zu erzeugen, siehe wsdl.exe oder xsd.exe.
Das ist abartig langsam wenn man es dazu missbraucht wiederholt on-the-fly IL zu erzeugen und benötigt temporäre Dateien.

In diesem Fall ist beides die sprichwörtliche Kanone für die Spatzenjagd. Ein generischer Container wie DataTable würde es genauso tun.

Original von BerndFfm
Hallo Cryo,
für so eine einfache SQL-Abfrage nimmt man eigentlich einen DataReader.
Das Ergebnis ist dann in dr[0] (wenn dr der DataReader ist). Wenn schon einen DataReader hernehmen, dann gleich richtig und das Ergebnis mit reader.GetInt32(0) holen. 😉
Wenn du den Indexer des Readers nutzt, könntest du ja gleich ExecuteScalar vom Command benutzen.
Hätte beides den gleichen Overhead...

Original von svenson
Ach, dass auch die Klasse statisch sein muss, war mir entgangen. Das entkräftet zumindest die meisten der Kritikpunkte. Die unsichtbaren Kopplungen bleiben allerdings. Aber da Extensions ja im IL-Code ausgezeichnet werden, kann ein Visualisierungstool diese Beziehungen ja wenigstens sichtbar machen. Ex-Methods sind nix weiter als statische Methoden, die mit dem ExtensionAttribute markiert werden, die Klasse selbst muss ebenfalls statisch sein und auch mit dem gleichen Attribut markiert sein.

Das ganze existiert auch nur in deinem Source, nicht im IL code.
Dem Compiler wird durch die Attribute nur gezeigt, dass er diese komische Methode, die er gar nicht in der Klasse finden kann, in einer andere Klasse suchen könnte.
Der Namespace der Extension class muss übrigens ebenfalls als using-clause benutzt werden.

Ist in Extension Methods eigentlich der Zugriff auf private Member der zu erweiternden Klasse erlaubt? Dürfte ja eigentlich nicht der Fall sein. Wie gesagt: keine Zauberei, nur statische Methoden.

Und wirklich Sinn macht das eigentlich nur bei generischen Methoden.
Nehmen wir mal einen abtrakten Bleistift:

[Extension]
public static class Miep
{
  [Extension]
  public static IEnumerable<T> GetItemsGreaterThan<T>(IEnumerable<T> items, IComparable<T> minValue)
  {
     foreach(T item in items)
       if(minValue.CompareTo(item) < 0)
         yield return item;
  }
}

Das ganze ließe sich jetzt so aufrufen:

int[] someInts = {1, 2, 3, 4, 5, 6};
foreach(int found in Miep.GetItemsGreaterThan<int>(someInts , 3))
  Console.WriteLine(found);

IMHO hübscher wäre es so:

int[] someInts = {1, 2, 3, 4, 5, 6};
foreach(int found in someInts.GetItemsGreaterThan(3))
  Console.WriteLine(found);

Wenn man es sinnvoll verwendet, lassen sich auf die Art etwas zu wortreiche Zeilen schön vereinfachen. (Für den Leser)

LINQ selbst benutzt Ex-Methods nur indirekt, da wir es dort mit syntaktischen Tricks zu tun haben, die wieder über syntaktische Tricks gestülpt werden.
Wenn deine Klasse/Interface zum Beispiel kein OrderBy enthält, aber irgendeine Extension class eine passende Methode zur Verfügung stellt, dann wird dieses OrderBy benutzt.
Praktisch eine Art Duck-typing für statische Methoden. 🤔

btw: Was wirklich interessant an Ex-Methods ist, ist die Frage ob MS sie weit genug abgespeckt hat, um die Patente von CodeGEAR/Borland zu Class helpers nicht zu verletzen. 😁

Original von Noodles
Ein Beispiel, wenn auch nicht ausprogrammiert siehst Du
> . In dem anderen Thread ging es um's Sortieren!
Auf konkreten Objekten generisch zu Filtern, mit nur einem String als Input, ist Wahnsinn, IMO.

@Goginho
Du könntest aber relativ einfach und ohne tiefgreifende Kenntnisse von C#, CLR und BCL einen Iterator über eine bestehende Liste stülpen:

public static IEnumerable<T> GetFilteredSlice<T>(IEnumerable<T> sourceSequence, Predicate<T> match)
{
   foreach(T item in sourceSequence)
     if(match(item))
       yield return item
}

Die Methode, die du der Funktion übergibst ließe sich wahrscheinlich auch recht einfach zusammen bauen.

Original von skulli
ja, hab ich schon probiert! funktioniert einwandfrei! die connection zum server ist auch da! Es könnte vielleicht hilfreich sein, wenn du uns das/die DML statement(s) zeigst. 😉

Stell' dir Boxing einfach so vor, dass eine Instanz einer Klasse erzeugt wird, die deinen ValueType als Feld besitzt. Unboxing kannst du dir vorstellen, als wenn der Wert dieses Feldes wieder zurückgegeben wird.
Das ist nicht 100% exakt, aber genau genug um es sich besser vorstellen zu können. 😉
Ein boxed ValueType verhält sich in vielerlei Hinsicht wie ein Referenztyp.

Bleistift:

struct Sample
{
   public int Field;
   public override ToString()
   {
      return Field.ToString();
   }
}

static void Miep(object instance, object value)
{
   FieldInfo fi = instance.GetType().GetField("Field");
   fi.SetValue(instance, value);
}

static void Main()
{
  Sample s = new Sample();
  s.Field = 1;
  object o = s;
  Miep(o, 2);
  Console.WriteLine(o); // ergibt 2!
}

Original von der-basti
Ich bins nochmal.
Und zwar habe ich ein Problem mit dem "SortedSet".
Wie wende ich es auf eine IList an? Wenns geht mit CodeSnippes. Vielleicht verwenden wir beide einfach nur unterschiedliche Begriffe für die Benennung "Set", aber wie um alles in der Welt sollte ein Index bei einem Set auch nur ansatzweise sinnvoll sein?
ICollection<T> könnte ich voll und ganz nachvollziehen, aber IList<T>? 🤔

Original von LordHexa

System.Threading.ParameterizedThreadStart ts = delegate(object _URL)  
          {  
            Fire.split_uri(URL, UserAgent);  
          };  

Dieser Methodenaufruf gilt aber doch pro Thread oder nicht? Du hast einen Parameter _URL, aber du benutzt in der anonymen Methode nur URL.
Also greifst du immer noch auf den gleichen String zu.

Original von Borg
Ist in meinen Augen aber kein Bug, sondern falsch programmiert, da sich alle Threads eine (relativ) globale Variable line teilen. Dies kann natürlich nicht gut gehen.
Im anderen Beispiel hat ja jeder Thread eine lokale Variable (entspricht also dem o.g. ParametrizedThreadStart) und alles ist schick. Ooops, wollte Bug in Anführungszeichen setzen.
Der Compiler kann ja schlecht wissen, dass es hier asynchrone Calls sind und er wird unwissend drauflosoptimieren. 😉