Conversation
Third platform, and the one that is not a binding: Vonage's OpenTok.Client is already managed .NET. What it lacks is a WinUI 3 renderer, which OpenTok.Net.Win supplies; this wires both into the facade so the same OpenTokSession/Publisher/Subscriber code runs on Windows unchanged. Platforms/Windows implements every partial hook. Member names and types were taken by reflecting over OpenTokNetStandard.dll rather than guessed — its XML docs omit the event-args members entirely. Some of the shared API has no Windows equivalent: camera position, torch and zoom (desktop webcams have none), the end-to-end encryption secret, Pause/Resume, and all of OpenTokAudioSession (no CallKit analogue). All documented no-ops rather than throws — a facade whose common API throws on one platform is not a facade, and it would throw on the platform least likely to be tested first. OpenTokWindowsContext is new machinery with no counterpart on the other two heads. Windows is the only one whose SDK has an explicit Context, all three object types must share one, and it is built with an OpenTokDispatcher so events land on the UI thread — otherwise the first handler that touches XAML throws RPC_E_WRONG_THREAD. Reference counted, because a publisher can outlive the session it was published to. The -windows target frameworks are appended only when building on Windows, since no runner can build all three heads: ios needs Xcode, windows needs the Windows SDK reference packs. That leaves a macOS-packed package silently without Windows assets, so build/AddWindowsAssets.sh packs them separately and merges with the existing merge-packages.py, and CI gains an add-windows-assets job that asserts the merge actually landed rather than trusting exit 0. The MAUI sample gains a Windows head. Its permission call moves behind a CapturePermissions shim, matching the existing CaptureLifetime one: Windows desktop has no runtime prompt at all, and MAUI's Permissions API gives a version-dependent answer there that must not be read as a refusal. MainPage.xaml.cs still contains no platform branching. iOS and Android verified locally: facade, MAUI package and sample all build Release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…Windows in it The notes were written when 2.34.1.3 was only the Android pin fix, and were never revised once the Windows head landed in the same version. They now cover both, plus what has no Windows equivalent and why those are no-ops rather than throws, and the release ordering: OpenTok.Net.Win 2.34.1.1 has to be on nuget.org too, not just OpenTok.Net.Android 2.34.1.4. release.yml was publishing the wrong artifact. The pack job runs on macOS and cannot build a -windows target framework at all, so its output has no Windows assets whatsoever; add-windows-assets packs those and uploads the merged result separately. Publishing nuget-packages rather than nuget-packages-with-windows would have shipped a package that restores cleanly and then has nothing for a Windows head — silently, since NuGet only reports a missing target framework when something asks for it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.34.1.3 releases from the fix branch without Windows, so this branch is the next version rather than the same one. The facade revision goes to 4 and OpenTok.Net.Win is pinned at 2.34.1.4 — starting that package at .1 would have had a 2.34.1.4 facade wrapping OpenTok.Net.Android 2.34.1.4 alongside OpenTok.Net.Win 2.34.1.1, which is legal and unreadable. docs/release-notes/2.34.1.3.md goes back to describing only the Android pin fix, which is what that release now is; the Windows content moves to 2.34.1.4.md along with the release ordering that OpenTok.Net.Win must reach nuget.org first. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
add-windows-assets failed with NETSDK1147 asking for the android workload. The Windows pack ran dotnet pack on a project whose declared TargetFrameworks, on Windows, was the mobile list *plus* the Windows heads — so it tried to build android and ios there too. Appending was the wrong shape and not just an unlucky configuration: no machine can build all three heads, so a list naming all of them builds nowhere. Installing the android workload on the Windows runner would have papered over it and left the ios heads failing for a reason no runner can fix, since Xcode does not exist there. OpenTokWindowsOnly=true now replaces the list rather than extending it, so the two are mutually exclusive by construction: build/AddWindowsAssets.sh packs Windows alone, everything else packs the mobile heads, and merge-packages.py joins them. Selected by an explicit property rather than IsOSPlatform, because "am I on Windows" is not the question — a Windows machine can build the android heads perfectly well, it just must not be asked to while doing this. The MAUI sample gets the same treatment, where it matters more: a declared list naming an ios head on a Windows runner does not merely fail to build it, it breaks MauiVersion resolution for the head that can, which is the NU1015 trap that .csproj already documents. Verified by evaluating TargetFrameworks for both projects across both bands and both values of the flag — eight combinations, all correct — and the mobile path still builds Release on macOS. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three defects, all found by compiling locally rather than by another CI round trip — EnableWindowsTargeting=true restores the Windows reference packs on macOS, and -t:Compile stops before the Windows-only MakePri step. OpenTokSubscriber was missing GetCaptionsTranslationLanguageNative entirely (CS8795). Found by comparing every declared partial hook against every platform's implementations rather than by eye; it was the only one missing, on any platform. Windows cannot implement it the way the other two do, because OpenTok.Client's CaptionsTranslationLanguage is set-only. The shared setter reads the value back on purpose — the SDK silently declines a language it does not support — so the Windows head reports the requested value and says so, which is the least bad of returning null, throwing, or pretending. OpenTok.Net now references Microsoft.WindowsAppSDK itself. It compiles against FrameworkElement and DispatcherQueue directly, and relying on those arriving through OpenTok.Net.Win was fragile regardless of whether it happened to work. The MAUI handler had four CS0104 ambiguities. MAUI and WinUI name the same concepts identically — Grid, SolidColorBrush, HorizontalAlignment, VerticalAlignment — and a handler is the one place both are in scope, so the WinUI side is now aliased with a W prefix. Verified: all three Windows target frameworks compile for OpenTok.Net, the MAUI handler compiles at net9.0-windows, and iOS and Android still build Release unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…flight The pin is exact, so the Windows jobs here cannot run until the version named exists on nuget.org — restore fails with NU1102 and the Windows leg goes red for a reason unrelated to the change under review. OpenTok.Net.Win now publishes a beta from every pull request, so the answer is to point OpenTokWinPackageVersion at that beta until the real release. Said next to the property rather than only in the release notes, because that is where someone hits the problem. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…check-again Fix "add Windows assets to the packages" merge failure
This branch was previously deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.