Laden...

BLE nur für Universal Windows Plattform (UWP)?

Erstellt von AmpelB vor 7 Monaten Letzter Beitrag vor 7 Monaten 534 Views
A
AmpelB Themenstarter:in
39 Beiträge seit 2021
vor 7 Monaten
BLE nur für Universal Windows Plattform (UWP)?

Ich möchte mit einem Windows Programm mit einem BLE Gerät kommunizieren.

Wenn ich das Internet richtig verstehe, gibt es das aber nur für Universal Windows Plattform (UWP). Hier für gibt es auch Beispiele, die auch bei mir funktionieren.

Ich würde aber lieber das "normale .Net", idealerweise mit Windows Forms (aber schon .Net Core und nicht .Net Framework), benutzen. Das funktioniert aber nicht? Selbst bei einer Suche nach einem Windows SDK hieß es, dass BLE nur bei UWP benutzt wird. Das kann doch gar nicht sein, oder? Es gibt wohl eine Bluetooth API im "normalen?" Windows SDK. Aber BLE ist doch was anderes, oder? Wenn ich per dll einige Windows Routinen einbinde, und die dann in meinem C# Programm benutze, wäre das auch ein Weg. Vielleicht nicht der einfachste, aber ...

Bei NuGet gibt es auch einige BLE Pakete. Aber da steht doch auch nie Windows dran. Oder interpretiere ich da was falsch?

Hat jemand schon mal BLE unter Windows gemacht?

Gruß
Erwin

16.783 Beiträge seit 2008
vor 7 Monaten

Bluetooth ist eine Funktionalität, die vom Betriebssystem (und der Hardware darunter) zur Verfügung gestellt wird. Dazu gibt es viele Funktionen in der Win32 API.

.NET ist ein Cross-Platform SDK, für das Entwickeln von Software.
Willst Du Betriebssystem-spezifische Dinge umsetzen, dann stellt .NET für einige eben solche spezifischen SDKs (wie zB für Desktop) zur Verfügung. Das ist aber reiner Komfort, denn unter der Haube ist .NET einfach nur ein Wrapper der Win32 API.

Im Endeffekt kannst Du also alles Betriebssystem-spezifische ohne weiteres SDK umsetzen, indem Du einfach selbst direkt mit der Win32-API sprichst, wenn Dir was fehlt.

Aber da steht doch auch nie Windows dran. Oder interpretiere ich da was falsch?

Die werden ja Open Source sein - dann schau doch einfach in Quellcode.

A
AmpelB Themenstarter:in
39 Beiträge seit 2021
vor 7 Monaten

Die Artikel hatte ich noch nicht gefunden. Sie haben mich doch recht optimistisch gestimmt. Dann kommt aber das große ABER.

Der Artikel ist schon etwas älter und benutzt nicht das aktuelle .Net. Im aktuellen .Net wurde das Einbinden von Windows.winmd aber untersagt (NETSDK1130: Direkter Verweis auf Windows Metadata-Komponente nicht möglich - .NET CLI | Microsoft Learn). Ich wurde dann auf microsoft/CsWinRT: C# language projection for the Windows Runtime (github.com) verwiesen. Gemäß meinem Verständnis kann man damit eine UWP Bibliothek erstellen, die man dann in eine .Net Bibliothek umwandelt. Mit Hilfe des NuGet Pakets.

Das funktioniert bei mir aber auch nicht. Ich bekomme immer den Fehler: Das Projekt <die UWP Library> ist nicht mit net7.0-windows10.0.22621 (.NETCoreApp, Version=7.0) kompatibel. Das Projekt unterstützt Folgendes: uap10.0.17763 (UAP, Version=v10.0.17763)

Anscheinend kann man doch keine Bibiliothek von UAP mit .NETCoreApp verbinden. In deren Beispiel CsWinRT/src/Samples/NetProjectionSample at master · microsoft/CsWinRT (github.com) haben die aber auch ein UAP Projekt, was nichts von Windows benutzt. Die haben einfach einen mathematischen Rechner, dier plus, minus, usw. macht. Und deren UAP Projekt ist in C++. Meine Library aber in C#. Ich dachte aber, das macht keinen Unterschied.

Das scheint wohl alles nicht zu funktionieren. Und die Windows.Devices Teile (sind ja wohl der low level Zugriff auf die HW), in denen das BLE drin ist, gibt es anscheinen wirklich nur für UWP. Ich habe auch nach Win32 API Funktionen für BLE gesucht. Die scheint es aber komischerweise nicht zu geben. Ich habe wohl Bluetooth API (den Link finde ich im Moment nicht) gefunden. Das ist aber was anderes als Bluetooth Low Energy.

Es wurde unten gesagt, ich könnte in Sourcen von Open Source Projekten nachschauen. Das war für NuGet Paket gemeint, oder? Es gibt aber doch nicht von allen NuGet Paketen den Source Code, oder? Da muss ich vielleicht noch mal wühlen.

Generell bin ich wohl nicht der Einzige, der über dieses Problem gestolpert ist. Man findet wohl Fragen, aber keine Antwort, wie das ohne UWO funktioniert. Das ist schon blöd. Vielleicht hat ja noch jemand einen Tip.

16.783 Beiträge seit 2008
vor 7 Monaten

32 Feet ist das bekannteste Bluetooth Package im .NET Ökosystem
https://github.com/inthehand/32feet

Findet man eigentlich direkt, wenn man in GitHub nach .NET und Bluetooth sucht 😃

Wenn man im Projekt selbst dann nach Win32 sucht, kommt das raus
https://github.com/search?q=repo%3Ainthehand%2F32feet%20Win32&type=code

Das zeigt dann direkt die verwendeten Win32 nativen Methoden
https://github.com/inthehand/32feet/blob/5d60e4d2602b4b7dea2d1872ff4ef9074dff9d72/InTheHand.Net.Bluetooth/Platforms/Win32/NativeMethods.cs#L3

Alles da, wie oben beschrieben 😃

A
AmpelB Themenstarter:in
39 Beiträge seit 2021
vor 7 Monaten

32feet scheint ja doch alles zu haben, was ich brauche. Das wäre ja klasse.

Vielleicht bin ich jetzt ja ganz blöd.

Ich wollte das Beispiel 32feet/Samples/ConsoleBLETest at main · inthehand/32feet (github.com) hier laufen lassen. Also habe ich ein Konsolen-App Projekt erstellt. Also unter Projektvorlagen den Eintrag "Konsolen-App  Ein Projekt zum Erstellen einer Befehlszeilenanwendung, die mit .NET unter Windows, Linux und macOS ausgeführt werden kann" ausgewählt. Es gibt ja nur zwei Konsolen Vorlagen: diese und eine mit .NET Framework.

In dem Projekt habe ich dann das NuGet Paket InTheHand.BluetoothLE (4.0.33) installiert.

Unter Program.cs gibt es keine Main Funktion (finde ich ungewöhnlich, aber das haben die ja vielleicht so gemacht). Rufe ich dort 
bool allowed = await Bluetooth.GetAvailabilityAsync();
auf, bekomme ich false. Bei dem Beispiel steht auch, dass man eventuell eine Bluetooth Permission angeben muss. Wie das unter Windows funktioniert, steht dort aber nicht. Mir ist auch nicht bewusst, dass man dort eine Berechtigung vergeben kann bzw. muss. Die BLE UWP Testprogramme funktioniert ja auch auf dem Rechner.

Zuerst hatte ich die GetAvailability Abfrage nicht drin. Und ich habe Probleme mit dem async, await und task. Das habe ich bisher noch nie benötigt und bin da nicht sattelfest. Bei ScanForDevicesAsync bekomme ich eine Exception "Operation is not supported on this platform". Also funktioniert das doch nicht bei Windows?

Hier mal da aktuelle Program.cs:

// See https://aka.ms/new-console-template for more information

using InTheHand.Bluetooth;

bool allowed = false;

async Task<bool> TestDeviceDiscovery()
{
    Console.WriteLine("In DestDeviceDiscovery");
    return true;
    //var discoveredDevices = await Bluetooth.ScanForDevicesAsync();
    //Console.WriteLine($"found {discoveredDevices?.Count} devices");
    //return discoveredDevices?.Count > 0;
}

async Task<bool> TestAvailability()
{
    allowed = await Bluetooth.GetAvailabilityAsync();
    return allowed;
}

//bool allowed = await Bluetooth.GetAvailabilityAsync();
var availableTask = TestAvailability();
availableTask.Wait();
Console.WriteLine("allowed = " + allowed);

Console.WriteLine("Vor Funktionsaufruf");
var discoveredDevices = await Bluetooth.ScanForDevicesAsync();
Console.WriteLine("Nach Wait");
string line = Console.ReadLine();
16.783 Beiträge seit 2008
vor 7 Monaten

Zitat von AmpelB

Unter Program.cs gibt es keine Main Funktion (finde ich ungewöhnlich, aber das haben die ja vielleicht so gemacht).

Top-level statements - programs without Main methods

Stehst sogar im Kommentar der Datei ganz oben. Muss man halt lesen...

bekomme ich eine Exception "Operation is not supported on this platform". Also funktioniert das doch nicht bei Windows?

Du hast doch jetzt den Quellcode. Wieso nimmst Dir nicht 2 Minuten Zeit, schaust in den Quellcode und siehst sofort, warum die Exception geworfen wird.
Siehst sofort, dass es prinzipiell von Windows unterstützt wird - nur in gewissen Fällen nicht.

Zur Not nicht das Paket, sondern den Quellcode ziehen und damit debuggen.
Das ist der Sinn von Open Source - wende es an.

A
AmpelB Themenstarter:in
39 Beiträge seit 2021
vor 7 Monaten

Ich habe mir alles heruntergeladen und einiges geschaut und ausprobiert. Ich konzentriere mich jetzt mal auf InTheHand.BluetoothLE.

Das ganze scheint für das .Net Framework zu sein und nicht for .Net Core. Neben der Fehlermeldung, dass ich nicht den richtigen Android API level installiert habe, sagt er, dass .NETFramework V4.6.1 eingestellt ist, was bei mir nicht installiert ist. Ich habe im Projektfile dann alle Zielversionen außer Windows entfernt. Ich habe also nur net7.0-windows10.0.19041.0 übrig gelassen. Damit compiliert es dann.

Das Beispiel (ConsoleBLETest) hat als Zielframework .NET Core 3.1 angegeben. Da sagt er dann, dass man von einer .NETCoreApp kein net7.0... Projekt referenzieren kann. Bei dem DLL Project (also das BluetoothLE Projekt) kann man kein .NET Core als Platform eingeben. Auf der GUI akzeptiert er es nicht. Wenn ich im Projektfile TargetFrameworks auf netcoreapp3.1 setze (das steht bei der Console App), kommen 55 Fehler im DLL Projekt, dass die Namen im aktuellen Kontext nicht vorhanden sind.

Wenn ich das BLE DLL Projekt mit dem

Im Bluetooth DLL Projekt gibt es auch Win32 und Windows als Platforms. Im BLE Projekt nur Windows. Dort gibt es noch eine Wasm Platform. Die scheint aber was mit Java zu sein. So scheint es für mich, dass es bei BLE keine Win32 Implementierung gibt (was ich ja immer wieder feststelle). Unter Windows Platform wird auch ganz normal Windows.Devices verwendet, was es ja nur bei UWP gibt. Win32 scheint also wirklich kein BLE zu unterstützen. In den Win32 Platform sourcen des Bluetooth Projekts sind die normalen Bluetooth Strukturen der Win API benutzt. Das hilft halt nur bei BLE nicht.

Ich habe übrigens nicht herausgefunden, warum die Exception geworfen wird. Und hinter dem eingefügten Link habe ich auch nichts entsprechendes gefunden.

16.783 Beiträge seit 2008
vor 7 Monaten

Es ist super anstrengend Dir helfen zu wollen, wenn Du Sachen wie

Das ganze scheint für das .Net Framework zu sein und nicht for .Net Core.

raus haust, was man mit einem 3 Sekunden-Blick in der csproj vom Tisch hauen kann:

<TargetFrameworks>netstandard2.0;monoandroid10.0;xamarinios10;xamarintvos10;xamarin.watchos10;uap10.0;net6.0-windows10.0.19041.0;net6.0;net6.0-android;net6.0-ios;net6.0-maccatalyst;net7.0-windows10.0.19041.0;net7.0-android;net7.0-ios;net7.0-maccatalyst;net461</TargetFrameworks>

Und allein die Tatsache, dass 32Feet  wie erwähnt ein sehr weit verbreitetes Projekt ist, das von sehr großen Anwendungen erfolgreich verwendet wird, widerspricht völlig Deinen Aussagen. Auch Deine BLE Aussagen spiegeln sich nach einem kurzen Blick nicht im Quellcode wider.

Dinge wie

Bei dem DLL Project (also das BluetoothLE Projekt) kann man kein .NET Core als Platform eingeben. Auf der GUI akzeptiert er es nicht.

lesen sich für mich als wildes, planloses Rumstochern, das für mich keinen Sinn ergibt, warum Du das tun willst. Das macht hier null sinn.
Du kennst die Lib nun ~60min, machst irgendwas, was für mich jetzt keinen Sinn macht und sagst "geht nicht". Tjo. Ich zwing Dich nicht, die Lib zu nutzen, die andere Leute erfolgreich verwenden. Dann musst halt was anderes Suchen, wenn Du meinst die Lib hier geht nicht, kann nix, und was nicht alles.

Ich bin mir aber sehr sicher, dass auch Du Dein Thema zum Laufen bekommen wirst. Viel Erfolg 😃

A
AmpelB Themenstarter:in
39 Beiträge seit 2021
vor 7 Monaten

Zuerst einmal ein Wort zu dem letzten Kommentar:

Sorry, in meiner 30 jährigen Arbeit als professioneller Software Entwickler hatte ich bisher nicht so viel mit den Details der verschiedenen .Net Versionen zu tun. Von daher sehe ich nicht nach 3 Sekunden an einer längeren Liste von vielen Begriffen direkt was das alles bedeutet. Wenn ich alles wüsste, bräuchte ich ja nicht im Forum zu fragen.
Aber da will ich nun nicht drauf rumreiten, obwohl mich diese Antwort (vor allem das zwischen den Zeilen) doch sehr verärgert hat.

Mein Problem ist aber gelöst.

Wie ich ja geschrieben hatte, liegt BLE unter dem Windows Devices Namespace. Der steht aber nur zur Verfügung, wenn man unter "Version des Zielbetriebssystems" eine 10.xy auswählt. Gibt man dort 7.0 an, gibt es Devices nicht mehr. Das macht sogar (auch für mein nicht vollkommenes Wissen, was ich mir aber so zusammengesucht habe) Sinn. Das Net Core ist ja für verschiedene Plattformen gedacht. Selbst wenn ich nun also als Zielbetriebssystem Windows auswähle, dann aber als Version 7.0 auswähle, sage ich praktisch: Nimm nur das, was es auch in anderen Plattformen gibt. Damit fällt Devices raus. Es steht ja auch im Internet, dass Devices aus den höheren .Net Versionen herausgenommen wurde. Nun dachte ich aber, das gilt für das gesamte Framework. Wenn man also in seinem Projekt .Net 7.0 als Zielframework angibt, würde das nicht zur Verfügung stehen. Das ist aber wohl falsch.

Mit der richtigen Version des Zielbetriebssystems kann ich nun auch Code aus den UWP (UWP ist ja per Definition immer nur für Windows) Beispielen benutzen.

4.919 Beiträge seit 2008
vor 7 Monaten

Ja, UWP gibt es erst seit Windows 10 (daher muß es darauf eingeschränkt werden, wenn man explizit Funktionalität daraus benutzen möchte).

Zuerst gab es auch "win10" als Projekttyp, dies wurde dann aber auf "uap10.0" geändert, s.a. Target frameworks in SDK-style projects.