使用 Windows.Devices.Bluetooth 命名空间是否需要通用 Windows 平台？

Question

I am evaluating the feasibility of using Bluetooth Low Energy API from windows for an existing WPF application.

I noticed that UWP is mentioned all over the place in the documentation for the Windows.Devices.Bluetooth namespace. I tried creating a .NET console application but couldn't figure out how to bring this library in.

If I create a UWP console application and fix the version to 1803 for both min and max, then I CAN use this namespace without hiccup.

I want to know if UWP is required to use this namespace or not. In the event that UWP is required, my plan B was to interface with low-energy bluetooth devices in some other way, but I can't seem to find libraries on NuGet that aren't UWP either. Are there alternatives? Our end users are on Windows 10 tablets, but our existing application is WPF.

Answer 1

[Updated on 2018/11/16]

Thanks @Adam Braden - MSFT for improving my reply. Yes, you could call Windows.Devices.Bluetooth APIs from your desktop app.

You need to add reference to C:\\Program Files (x86)\\Windows Kits\\10\\UnionMetadata\\Windows.winmd and C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETCore\\v4.5\\System.Runtime.WindowsRuntime.dll .

Please see this blog Calling Windows 10 APIs From a Desktop Application for more information.

Please note that If you want to call UWP APIs from desktop app, you first need to confirm if it's supported in classic desktop app. See UWP APIs callable from a classic desktop app to learn how to determine if the API is available in desktop app.

Answer 2

With .Net 5, Microsoft removed built-in support for the consumption of WinRT API's:

Previously, CoreCLR could consume Windows metadata (WinMD) files to active and consume WinRT types. Starting in .NET 5, CoreCLR can no longer consume WinMD files directly.

If you attempt to reference an unsupported assembly, you'll get a FileNotFoundException. If you activate a WinRT class, you'll get a PlatformNotSupportedException.

However, there is a recommended solution and that is to change the target framework moniker (TFM). For example, in your project file (assuming you are targeting .Net 5):

<!-- Change from -->

<TargetFramework>net5</TargetFramework>

<!-- To -->    

<TargetFramework>net5.0-windows10.0.19041</TargetFramework>

This will provide access to the API's (although there are still some exceptions to specific API's).

At the time of writing this, the available TFM's are:

Replace the value of the TargetFramework element with one of the following strings:

• net5.0-windows10.0.17763.0: Use this value if your app targets Windows 10, version 1809.
• net5.0-windows10.0.18362.0: Use this value if your app targets Windows 10, version 1903.
• net5.0-windows10.0.19041.0: Use this value if your app targets Windows 10, version 2004.

For more information, you can see the Built-in support for WinRT is removed from .NET web page from Microsoft and for a detailed description on what options are available, see the Call Windows Runtime APIs in desktop apps web page.

Answer 3

I want to amend these helpful answers and point out something I found that's relatively new:

TL;DR: You just need to pull in Microsoft.Windows.SDK.Contracts from NuGet to call Windows 10 runtime APIs.

https://blogs.windows.com/windowsdeveloper/2019/04/30/calling-windows-10-apis-from-a-desktop-application-just-got-easier/