WakeOnLAN Library 1.6 [04.12.2013] — Jetzt open source.

Ich habe jetzt alle Async-Methoden so umgeschrieben, dass sie einen Task zurückgeben.
Jetzt stellen sich mir 2 Fragen:

1. Ich hab das mit dem Async-Pattern noch nicht so ganz verstanden. Muss die Methode, die einen Task/Task<T> zurückgibt, mit dem async-Modifier gekennzeichnet sein? Ich bin der Meinung nein, aber in vielen Beispielen wurde das gemacht.

2. ist ein Async überhaupt nötig? Blockt UdpClient.Send überhaupt den Thread? Ich habe die Erfahrung noch nicht gemacht, aber vorsichtshalber mal implementiert.

Sollte man die Kennzeichnung mit async benötigen, werde ich das allerdings nicht machen, da ich mir nicht die .NET 4.5 Beta installieren möchte.

picoflop schrieb:

da bei UDP ja nicht auf Antwort gewartet werden muss.

Genau deshalb kam ich ja zu der Überlegung, ob es den Thread nenneswert blockt. Aber okay, ich werde es jetzt so machen.

picoflop schrieb:

Das CTP Async reicht ja (wenn man 2010 SP 1 drauf hat) ;)

Wenn ich keinen async-Modifier setzen muss, reicht dann nicht auch 4.0? Dann müsste halt nur der Anwender 4.5 verwenden.

picoflop schrieb:

Der Programmierer braucht zwingend 2010 SP1 (oder eben Beta 11), weil "Async" beim kompiliern ausgewertet wird und der IL-Code dann halt die notwendigen Callbacks etc enthält.

Dann kann ich es ja in .NET 4.0 ausliefern. Um die restlichen Libraries kann sich dann der Programmierer kümmern. Sonst treten nur Versionskonflikte (bezüglich der Async-Lib) auf.

Habe die Library mal geupdated. Alles im Eingangspost.

Die Async-CTP-Teile buggen noch etwas. Ich werde es morgen/heute beheben.

Nein, die Mac-Adresse wird benötigt.

Es gibt jedoch eine Möglichkeit (ich glaube sogar via WinAPI), sich die MAC-Adresse via ARP zu holen. In die Library selber werde ich das nicht rein packen, da die mir diese Methode zu unzuverlässig funtkioniert.

Ich habe übrigens noch ein paar Verbesserungen gemacht, die ich morgen über ein Update einbringen könnte.

Übrigens befindet sich die Library schon im produktiven Einsatz und weckt jeden Samstag 15 Rechner auf. :)

Hi,

würde daran Interesse bestehen, wenn ich die Library um ein paar Subnetting-Funktionen erweitern würde?

Hab aus Langeweile mal etwas herumgebastelt. damit wäre es z. B. sehr einfach möglich, das ganze Netzwerk anzupingen:




Einbauen? (Hat ja thematisch nichts mit WakeOnLan zu tun, deshalb frage ich)

Ich habe gerade gesehen, dass es im .NET-Framework schon eine Klasse für MAC-Adressen gibt.
Diese findet ihr hier: System.Net.NetworkInformation.PhysicalAddress
Von daher werde ich in den zukünftigen Versionen die MacAddress-Klasse entfernen. Die Migration der bestehenden MacAddress-Klasse auf die .NET-Klasse sollte aber nicht sonderlich aufwändig sein. Trotzdem werde ich "meine" Klasse sie erst einmal als obsolet markieren.
Die Erweiterungsmethoden werde ich auf die Framework-Klasse portieren. Die "alten" für die "alte" Klasse werde ich als obsolet markieren. Zusätzlich werde ich eine ToPhysicalAddress()-Funktion hinzufügen, um die Migration zu vereinfachen.

Hier mal ein paar Unterschiede:

• Die Parse-Funktion:
  Es müssen Bindestriche als Trennzeichen verwendet werden. Die Trennzeichen können alternativ auch weggelassen werden. Außerdem müssen die Zeichen alle in GROßSCHRIFT übergeben werden. Es gibt keine TryParse-Funktionalität.
  Informationen zu der Parse-Funktion des Frameworks
  
  
• Die Address-Property, welche die Bytedaten der Adresse abruft, hat die gleiche Funktionalität wie die PhysicalAddress.GetAddressBytes()-Funktion. Eine Eigenschaft gibt es also nicht.
  Achtung, der Rückgabewert ist nicht immer 6-Bytes lang, zum Beispiel beim PhysicalAddress.None-Feld. Diese Funktion gibt eine Kopie der Bytes im Konstruktor zurück.
  
  
• Es gibt nur einen Konstruktor, welcher ein Byte-Array entgegennimmt. Die Länge dieses Arrays wird nicht eingeschränkt. Es können also Mac-Adressen beliebiger Länge verwendet werden.
  
  
• Eine Broadcast-Property (gibt die Mac-Adresse FF:FF:FF:FF:FF:FF zurück) gibt es in der .NET-Klasse nicht. Eine Alternative existiert auch nicht. Diese muss manuell implementiert werden.
  
  
• In der Framework-Klasse gibt es ein None-Feld. Dieses Feld ist wie folgt definiert:
  

  C-Quellcode

  1. PhysicalAddress.None = new PhysicalAddress(new byte[0]);
  
  Informationen zu diesem Feld
  
• Die PhysicalAddress-Klasse ist nicht serialisierbar.
  

Ich werde außerdem noch Erweiterungsmethoden hinzufügen, die es ermöglichen, zu schauen, ob eine MAC-Adresse Uni- oder Multicast, Globally Unique oder Locally Administrated ist. Da muss ich mich aber noch weiter einlesen.

Zum Subnetting:
Im Framework gibt es Methoden, die IPv4-Subnetzmaske eines Adapters auszulesen.
Eine Lösung dazu findet Ihr hier: blogs.msdn.com/b/dgorti/archive/2005/10/04/477078.aspx
Es gibt also die Eigenschaft: UnicastIPAddressInformation.IPv4Mask
Diese Eigenschaft ist vom Typ IPAddress. Daraus schließe ich, dass im .NET-Framework keine Klasse für Netzmasken existiert. Puh.
(Falls es doch eine gibt, bitte schreiben!)
Ich werde diese Klasse wohl in der nächsten Version der Library hinzufügen. Außerdem werde ich zur Kompatibilität mit dem Rest des Frameworks einen Konstruktor hinzufügen, der eine IPAddress entgegennimmt.

Ich habe übrigens die Lizenz geändert. Mehr Informationen dazu findet Ihr im ersten Post.

Hier eine Liste mit dem, was ich in den letzten Tagen implementiert/geändert habe:

• ToPhysicalAddress()-Funktion zur MacAddress-Klasse hinzugefügt
  
• MacAddress-Klasse als obsolet markiert
  
• Die entsprechenden Methoden als obsolet markiert
  
• Sämtliche Methoden und Erweiterungsmethoden, die die MacAddress-Klasse verwendeten, auf PhysicalAddress umgeschrieben
  
• Separat kompilierte Versionen für .NET 4.5 und .NET 3.5 (damit dei CLR 4.0 und 2.0 unterstützt werden; aus Kompatibilität)
  - Warum 3.5 und nicht 2.0? 2.0 kann keine Erweiterungsmethoden.
  
• "Richtiger" Support des neuen Async-Patterns TAP (nur in der 4.5er-Version enthalten)
  
• SercureOn-Password-Support verbessert
  
• Erweiterungsmethoden für die PhysicalAddress-Klasse des Frameworks hinzugefügt:
  - GetAddressType()
  - GetAddressAdministrator()
  
• 2 Enumerationen hinzugefügt:
  - PhysicalAddressType (Unicast/Multicast)
  - PhysicalAddressAdministrator (Global/Local)
  
• Verbesserung in der Lokalisierung
  

Habt ihr noch was, was unbedingt in den nächsten Release muss?

So, hier das versprochene Update.

Ich habe die Library nun für 3 verschiedene Framework-Versionen kompiliert: 2.0, 3.5 und 4.5. (Conditional Compiling ftw)

Bei 2.0 fehlt:
- Extension Methods
- Die MacAddress-Klasse
- TAP-Support (async/await)

Bei 3.5 fehlt:
- TAP-Support (async/await)

Bei 4.5 fehlt:
- Nichts

Ich bin am überlegen, ob ich noch eine Version für .NET 4.0 kompiliere. Ich lasse es aber erstmal bei diesen drei.
Was ich mit dem Subnetting mache, weiß ich noch nicht. Mal sehen.

Download gibt's wie immer im ersten Post.
Hatte gerade etwas langeweile. Deshalb hab ich mich mal an Sandcastle gesetzt und eine Online-Dokumentation erstellt (ja, ich weiß; etwas übertrieben).
Diese findet Ihr im ersten Post unter den Downloads.

Außerdem habe ich die Library kurz aktualisiert. Es gibt jetzt auch eine .NET 4.0-Version, die der 3.5er gleicht. Nur die Framework-Version ist anders (kein TAP-Support).

Im laufe der Woche werde ich den Code der WakeOnLAN-Library nach C# migrieren, um ihn dann auf meinem GitHub-Repo als OpenSource zur Verfügung zu stellen. Diesen Thread hier werde ich dann auch in den anderen Showroom packen.
Die zukünftigen Releases werden dementsprechend C# verwenden und mit einem CodeSigning-Zertifikat signiert sein. "Nightly Builds", könnt Ihr Euch dann selber kompilieren, indem Ihr mein Git-Repo klont. Ich würde mich auch über den ein oder anderen Fork freuen.
Ich meld' mich dann wieder.

Ich habe mich heute rangesetzt und den Quellcode in zweistündiger Arbeit nach C# migriert.
In der GitHub-Version werden sich immer Features vor der aktuellen Showroom-Version befinden. Aktuell ist dort auch eine fertige Klasse für ARP-Requests (hab ich heute gleich noch gemacht). Diese wird erst in der nächsten Showroom-Version (1.6) enthalten sein. Ich selber habe keine weiteren Features geplant. Falls Ihr aber Ideen habt, so tut Euch keinen Zwang an und schreibt es oder macht es selber.

Den Source Code bzw. das Git-Repo findet Ihr hier:
github.com/nikeee/wake-on-lan-library
Aktuell steht die WakeOnLAN-Library unter der LGPLv3.0.
Ich würde mich über externe Beteiligung am Code freuen!

Ich habe nun auch ein NuGet-Package erstellt. Beim Installieren wird automatisch die Version für die entsprechende .NET-Version referenziert.
Um das Paket zu installieren, einfach in der Package Manager Console Install-Package WakeOnLAN ausführen.
Außerdem habe ich eine Version für .NET 4.5.1 hinzugefügt.

thefiloe schrieb:

mit was hast du die Online-Doku generiert?

Die habe ich mit Sandcastle gemacht (zusammen mit dem Sandcastle Help File Builder). Ein Tool von MS, was seit Ewigkeiten nicht mehr weiterentwickelt wird. Leider.
Sandcastle generiert die Doku aus den XML-Kommentaren im Quelltext.

thefiloe schrieb:

Guidelines eingehalten

Leider nicht überall. Der Stammnamespace dürfte z. B. nicht System.Net sein. Das habe ich aber so gemacht, da das am Ende intuitiver zu benutzen ist.

thefiloe schrieb:

Alles in allem sehr schön und gut gemacht.

Danke. Ich werde in nächster Zeit mal ne kleine Demo-Anwendung machen, die das Netzwerk scannt und sich die MAC-Adressen via ARP-Request holt.

Mal schauen, ob ich die Library auch auf Silverlight und Windows Store Apps portieren kann. Sollte ja nicht so schwer sein.