Will dotnet team consider something about Bluetooth? e.g. Microsoft.Extension.Bluetooth ?

[wsy]

I'm planning to use Bluetooth with my .Net Console Application.
After I searched Google about Bluetooth, everything was related to UWP or C/C++ Interop.
I wonder why there's no general library that works with console applications.

[elgonzo]

After I searched Google about Bluetooth, everything was related to UWP or C/C++ Interop.

32feet.NET (I have no experience with this library myself, it just appeared multiple times in the search result when googling for "C# bluetooth", and it is actively maintained as far as i can tell...)

[wsy]

Thanks, but from its description, this is for Personal Area Networking.

[KeterSCP]

Bluetooth is a part of Personal Area Networking. And that library has support for Bluetooth Classic and BLE.

[teo-tsirpanis]

I believe this is too specific to include in the .NET Base Class Libraries.

[danmoseley]

First, I don't consider "Microsoft.Extensions.*" as Base Class Libraries.

Personally (and I used to own them) I avoid the term BCL and just use "core libraries" by which I mean vaguely "the stuff you get in the .NET SDK". "Microsoft.Extensions" namespace is a bit of a historical accident that came about as two teams worked in parallel and one of them owned "System" -- some of the API in Microsoft.Extensions could arguably be in System, and at a minimum it's not a great name.

Whatever you call it, what goes in there is more or less: the base you need to create apps ("table stakes" like Dictionary, Http and Json); anything that those must depend on themselves; anything that needs special runtime knowledge (and therefore goes in System.Private.Corelib). Anything new generally needs to be cross platform. They are supported indefinitely, and aim to avoid anything fashionable or opinionated, where the ecosystem could move more quickly and offer a range of options. You could make an argument that something like Bluetooth is analogous to Http, but it would be a big investment to create something new and cross platform. Like for GraphQL we would rather help encourage ecosystem projects not undermine them. It is not a goal for the .NET SDK to be the ecosystem.

For Windows.Devices.Bluetooth clearly it's Windows only. @tommcdon is there a story for a non UWP app to conveniently consume something like that?

[wsy]

OK. Now I understand and agree that "Microsoft.Extensions.*" packages shall be classified as "core libraries".

For Windows.Devices.Bluetooth clearly it's Windows only.

I understand that Bluetooth-related API might be platform-specific.
But I think it's OK that Microsoft publishes platform-specific packages to Nuget. In this case the Bluetooth package with package name starting with "Windows".

If Microsoft can decouple Windows.Devices.Bluetooth from Windows SDK and publish it to Nuget, developers will be able to utilize Bluetooth capability without having to use UWP or MAUI. Meanwhile, UWP and MAUI developers can stay unaffected.

[danmoseley]

I meant it should ideally be like SerialPort .. same API same package for all platforms.

Anyway the question is who owns this and whether they'd be motivated to do that. Maybe @jkotas knows.

[jkotas]

developers will be able to utilize Bluetooth capability without having to use UWP or MAUI.

You do not have to use UWP or MAUI to use Windows SDK.

For example, this console app is going to enumerate all devices on the system:

using Windows.Devices.Enumeration;

var all = await DeviceInformation.FindAllAsync();
foreach (var device in all)
{
    Console.WriteLine(device.Name);
}

(Make sure to have -windows target framework in your .csproj file. Like <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>.)

I meant it should ideally be like SerialPort .. same API same package for all platforms.

https://github.com/dotnet/iot is probably the best repo in the dotnet org to discuss a design of portable Bluetooth nuget package like SerialPort.

[wsy]

OK, thanks.
Your solution works!
I tried <TargetFramework>net8.0-windows</TargetFramework> before, but I did not include a version number.
Now I added version number 10.0.19041.0 and the namespace Windows.Devices.Enumeration became available.