3.1.0

[janusw]

What's Changed

(relative to 3.0.0)

• Make the Maui sample client work on Windows by @janusw in Make the Maui sample client work on Windows #758
• Some package updates in Plugin.BLE.Tests and BLE.Client by @janusw in Some package updates in Plugin.BLE.Tests and BLE.Client #759
• Windows.Devices.Bluetooth Only by @AskBojesen in Windows.Devices.Bluetooth Only #746
• ReadAsync updates characteristic value on Windows by @Praseodymi in ReadAsync updates characteristic value on Windows #764
• Remove .NET 6 by @janusw in Remove .NET 6 #770
• Added BroadcastName to AdvertisementRecordType by @janmarektelc in Added BroadcastName to AdvertisementRecordType #773
• disable MainThreadInvoker in Adapter.ConnectToDeviceAsync by @janusw in disable MainThreadInvoker in Adapter.ConnectToDeviceAsync #774
• StateChanged for Windows by @AskBojesen in StateChanged for Windows #777
• Add support for .NET 8 by @janusw in Add support for .NET 8 #778
• Improve Connect In Windows by @AskBojesen in Improve Connect In Windows #776
• GHA: add a Linux build by @janusw in GHA: add a Linux build #791
• Turn Bluetooth Radio On/Off by @AskBojesen in Turn Bluetooth Radio On/Off #784
• Connection parameters for windows by @AskBojesen in Connection parameters for windows #801
• GHA: build Maui client on Windows by @janusw in GHA: build Maui client on Windows #806
• Added services for citysports treadmill by @hughesjs in Added services for citysports treadmill #805
• Fix GetSystemConnectedOrPairedDevices in Windows by @AskBojesen in Fix GetSystemConnectedOrPairedDevices in Windows #807
• Fix ConnectionLost -> Connect for Windows by @AskBojesen in Fix ConnectionLost -> Connect for Windows #809
• Fix some warnings by @janusw in Fix some warnings #811
• Implement BleImplementation.TrySetStateAsync on Android by @janusw in Implement BleImplementation.TrySetStateAsync on Android #823
• Fix a NullReferenceException in Characteristic.NSErrorToGattStatus by @janusw in Fix a NullReferenceException in Characteristic.NSErrorToGattStatus #827
• Windows Implementation for BondAsync and BondedDevices by @AskBojesen in Windows Implementation for BondAsync and BondedDevices #820
• Maui client update by @jeetee in Maui client update #837
• Windows: Handle that a device is already connected by @AskBojesen in Windows: Handle that a device is already connected #839
• fix Device.UpdateRssiAsync on Windows by @janusw in fix Device.UpdateRssiAsync on Windows #844
• Implement Adapter.SupportsExtendedAdvertising on Windows by @janusw in Implement Adapter.SupportsExtendedAdvertising on Windows #845
• Windows: Fixed null entries in DiscoveredDevices [WinUI] [3.1.0-beta.1] introduces null IDevice(s) to device lists #828 by @AskBojesen in Windows: Fixed null entries in DiscoveredDevices #828 #848
• Windows: Connect -> ConnectionLost -> Reconnect by @AskBojesen in Windows: Connect -> ConnectionLost -> Reconnect #849
• Windows: Check for OS build number version Runtime by @AskBojesen in Windows: Check for OS build number version Runtime #853
• fix Bluetooth stack breaks when trying connect on phone boot #854 - Bluetooth stack breaks when trying connect on phone boot by @alex3696 in fix #854 - Bluetooth stack breaks when trying connect on phone boot #855
• Fixed StartUpdatesNativeAsync for indicate by @AskBojesen in Fixed StartUpdatesNativeAsync for indicate #858

New Contributors

• @AskBojesen made their first contribution in Windows.Devices.Bluetooth Only #746
• @Praseodymi made their first contribution in ReadAsync updates characteristic value on Windows #764
• @janmarektelc made their first contribution in Added BroadcastName to AdvertisementRecordType #773
• @hughesjs made their first contribution in Added services for citysports treadmill #805
• @jeetee made their first contribution in Maui client update #837
• @alex3696 made their first contribution in fix #854 - Bluetooth stack breaks when trying connect on phone boot #855

Full Changelog: 3.0.0...3.1.0

---

This discussion was created from the release 3.1.0.

[AskBojesen]

@janusw : I have a suggestion for the version numbering of the next release.
My problem with the current versioning scheme is that the assembly version and file version has been 3.1.0.0 constantly during the development for the Plugin.BLE.dll

The Windows installer I use for tools differentiates only using the file version, so an update does not update the dll.
Can you maybe increase the patch number during development and release, so they in fact get a different file version?
Eg. 3.1.0.234

[janusw]

@janusw : I have a suggestion for the version numbering of the next release. My problem with the current versioning scheme is that the assembly version and file version has been 3.1.0.0 constantly during the development for the Plugin.BLE.dll

The Windows installer I use for tools differentiates only using the file version, so an update does not update the dll.

I was not aware of this problem.

What we have been doing so far is this:

• The <Version> in the csproj files is only updated for tagged versions (e.g. 3.1.0-beta.2 or 3.1.0-rc.1), but not in between.
• The version of the nupkg files built by GitHub Actions is set via git describe (something like 3.1.0-rc.1-19-g1e19fa8).

I think the <FileVersion> and <AssemblyVersion> are set from the <Version>, but their format is more restricted (major.minor.patch.build). Since we're only using major.minor.patch in the tags, the build number is always 0 this way and we end up with 3.0.0.0 or 3.1.0.0.

Can you maybe increase the patch number during development and release, so they in fact get a different file version? Eg. 3.1.0.234

Well, I guess we don't want to set the <FileVersion> and/or <AssemblyVersion> manually in each commit, but it should e.g. be possible to set them automatically in GHA.

Do you have any suggestions how to best handle this in a somewhat automated fashion?

[jeetee]

A possible approach I'm trying out on some projects is to use the build datetime as FileVersion. Assembly Version then stays as per release numbering.

<!-- Using Build DateTime as Assembly File Version, Revision is seconds/2 to fit within uint16 --> <FileVersion>$([System.DateTime]::UtcNow.ToString('yyyy.MM.dd')).$([System.Convert]::ToUInt16($([MSBuild]::Divide($([System.DateTime]::UtcNow.TimeOfDay.TotalSeconds), 2))))</FileVersion>

Which'll lead to a FileVersion looking like 2024.5.23.39408 for example; the upside (in my very humble opinion) is that you can use FileVersion to always identify a newer vs older file (if builds differ at least 2s).

[janusw]

A possible approach I'm trying out on some projects is to use the build datetime as FileVersion. Assembly Version then stays as per release numbering. [..]
Which'll lead to a FileVersion looking like 2024.5.23.39408 for example; the upside (in my very humble opinion) is that you can use FileVersion to always identify a newer vs older file (if builds differ at least 2s).

Well yes, but that only tells you something about the build date. You'd have no idea if that build was from current master (3.1.0+) or from some old branch (e.g. v3.0.0 or v2.1.3).

My idea would rather be to use major.minor.patch from the tags, as it is currently done, and then maybe have the build number as the number of commits since the last tag (or the last stable/annotated tag, to be precise).

So the third commit after the tag 3.1.0 would have the version 3.1.0.3. That still does not tell you whether the commit is on the master branch or some other experimental branch, but at least you get a rough idea where you are in the versioning scheme, and all commits on master would have a unique and increasing number.

[jeetee]

True.. We use FileVersion indeed as only that.
Then we make use of VersionPrefix (which can be provided via build parameters) to contain Major.Minor.Patch (based of the tag) and VersionSuffix, (defaults to 'dev' for local builds, could indeed be your proposed commit count).

We configure AssemblyVersion to match VersionPrefix to avoid it expanding with the .0 revision number. So in our usage AssemblyVersion is the main indicator and FileVersion is used as a pure build indicator.

But for the purpose here I'd then propose to configure AssemblyVersion as Version so it'd retain the counting number from the suffix

<!-- The prefix contains jist Major.Minor.Build information -->
<VersionPrefix Condition="'$(VersionPrefix)' == ''">0.1.0429</VersionPrefix>
<!-- We use a default suffix to indicate development builds if no suffix was set -->
<VersionSuffix Condition="'$(VersionSuffix)' == ''">dev</VersionSuffix>
<!-- The version number actually used for assembly matching/linking
	For libraries: Should only change when breaking compatibility
	For applications: Should change each release -->
<AssemblyVersion>$(Version)</AssemblyVersion>
<!-- Using Build DateTime as Assembly File Version, Revision is seconds/2 to fit within uint16 -->
<FileVersion>$([System.DateTime]::UtcNow.ToString('yyyy.MM.dd')).$([System.Convert]::ToUInt16($([MSBuild]::Divide($([System.DateTime]::UtcNow.TimeOfDay.TotalSeconds), 2))))</FileVersion>
<!-- Don't set InformationVersion, it'll default to $(Version) with $(SourceRevisionId) appended to it. This is the field visible as Product Version in the Detailed File Properties window in Windows Explorer -->

[axa88]

@AskBojesen @janusw

Ive installed this latest 3.1.0 as confirmed in VS:

Ive cleaned the solution, deleted the obj and bin folders, rebuilt, and when i attempt to BOND on windows Im getting an exception due to this comparison of the NativeDeivice in Source/Plugin.BLE/Windows/Adapter.cs

public override async Task BondAsync(IDevice device)
{
	if (!(device.NativeDevice is BluetoothLEDevice bluetoothLEDevice))
	{
		Trace.Message($"BondAsync failed since NativeDevice is null with: {device.Name}: {device.Id} ");
		return;
	}
   ...
}

But as far as I see that is invalid, and the master and 3.1.0 tag repos both have:

public override async Task BondAsync(IDevice device)
        {
            var bleDevice = device.NativeDevice as BluetoothLEDevice;
            if (bleDevice is null)
            {
                Trace.Message($"BondAsync failed since NativeDevice is null with: {device.Name}: {device.Id} ");
                return;
            }
    ...
}

Could something have been built wrong in the 3.1.0 nuget?
Does the version of windows targeted matter?
Im about to throw my pc out the window... any help is appreciated.

[janusw]

Ive cleaned the solution, deleted the obj and bin folders, rebuilt, and when i attempt to BOND on windows Im getting an exception due to this comparison of the NativeDeivice in Source/Plugin.BLE/Windows/Adapter.cs

public override async Task BondAsync(IDevice device)
{
	if (!(device.NativeDevice is BluetoothLEDevice bluetoothLEDevice))
	{
		Trace.Message($"BondAsync failed since NativeDevice is null with: {device.Name}: {device.Id} ");
		return;
	}
   ...
}

Where does the code that you quote here even come from? It's not in the repo.

But as far as I see that is invalid, and the master and 3.1.0 tag repos both have:

public override async Task BondAsync(IDevice device)
        {
            var bleDevice = device.NativeDevice as BluetoothLEDevice;
            if (bleDevice is null)
            {
                Trace.Message($"BondAsync failed since NativeDevice is null with: {device.Name}: {device.Id} ");
                return;
            }
    ...
}

Yes, this was added in #820 (before 3.1.0-rc.1).

Could something have been built wrong in the 3.1.0 nuget?

I doubt it. Instead, could it be that you local package cache is somehow messed up? Have you possibly built a package yourself with version 3.1.0 that is still lingering in the package cache?

Does the version of windows targeted matter?

In general: Yes, it matters. But what are you asking specifically? Does it matter for what?