Errors/Warnings building SIPSorcery and AndroidSIPGetStarted projects in VS2022

[Astrogator7]

Hello!

I'm looking for a SIP library with C# interface for simple VoIP functionality (G711, uLaw, 8kHz, 16bit, one direction only - out) for use in an Android app in Xamarin (still available in project templates, though claimed no longer supported) or MAUI.
Discovering SIPSorcery was very promising, so I started to evaluate.  Upon cloning the source tree I'm trying to compile AndroidSIPGetStarted sample project and keep stumbling.

The first issue right on opening the solution was that VisualStudio prompted me to install .NET Core 3.1 and .NET 5.0.  Both out of support today, 1.4 GiB of more crap on my drive.. - so I said "no".
Opened the SIPSorcery.csproj file and changed TargetFrameworks to only net462;net8.0 - the only frameworks I care about. That resulted in NU1201 error (Project SIPSorcery is not compatible with monoandroid90..).
I added ;monoandroid90 to TargetFrameworks.  NU1201 error disappeared, but got replaced by these 2 warnings:

1. MSB3644 (The reference assemblies for MonoAndroid,Version=v9.0 were not found..), and
2. MSB3270 (There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll", "x86"..)

If monoandroid90 is removed from SIPSorcery.csproj's TargetFrameworks, that project compiles successfully (yay!).
But then trying to compile AndroidSIPGetStarted project results in NU1201 shown above.

I'm puzzled by MSB3270, as any processor architecture choice I can find shows Any CPU. Also, why does a child project force its parent's references (Mono.Android 9.0 in this case), when parent is very much compilable without it (thus parent itself does not use it)?

Is there any way to solve this and move forward?

I very much appreciate the work you've done to make this a clean, well documented and pristine-C# implementation, and would love to make it fit!  Thank you for all the efforts!

P.S. I can add screenshots detailing the errors/warnings if needed.

[sipsorcery]

It's been a long time since I (and as far as I know anyone else) has done any serious work on any of the Xamarin demos. They are very much obsolete at this stage. I can't offer much help on the Android questions. It's also not something I've spent time on recently.

[Astrogator7]

Pity..  I appreciate your fast response!
I've read some Qs and issues and got a sense that handling audio on Android in .NET is not straightforward.  I'd love to contribute to the project if any headway happens, but am not sure I know enough about that platform, esp. hardware related stuff ((.  Dang!

[Senthil455]

You're running into a mix of two separate issues here: outdated Xamarin targets and how the solution is structured.
The NU1201 error happens because the Android sample project targets monoandroid, but your modified SIPSorcery project no longer includes that target. So the dependency chain breaks. Even if SIPSorcery itself compiles fine for net462 or net8.0, the Android project still expects a MonoAndroid-compatible build.
The MSB3644 warning is basically Visual Studio telling you that the Android/Xamarin reference assemblies are missing. That usually means the required workload (Mobile development with .NET / Xamarin) isn’t installed. Since Xamarin is now deprecated, VS won’t have those components by default.

The MSB3270 architecture warning is less critical. It typically shows up when there’s a mismatch between AnyCPU and x86 references, and in many cases it doesn’t actually block the build.
Given the maintainer’s comment that the Xamarin demos are obsolete, you’ve got a couple of practical options:
If your goal is just to use SIPSorcery itself, keep it targeting net8.0 (or netstandard where needed) and ignore the Android sample project entirely. The core library builds fine without MonoAndroid.
If you specifically need Android support, it’s better to move toward .NET MAUI or a newer Android approach instead of Xamarin. You’ll likely need to handle audio integration separately anyway, since platform-level audio handling isn’t fully abstracted.

If you still want to try building the sample, you’ll need to install the legacy Xamarin/Android workloads and keep monoandroid in the target frameworks so the dependency chain stays valid.
So in short, nothing is “wrong” with your setup — you’re just hitting the limitations of an outdated sample project. The cleanest path forward is to focus on the core library and use a modern Android stack around it.