feat: add Aptabase.Core

[BrycensRanch]

Keeps all dependencies on MAUI in Aptabase.Maui but also moves all the independent code to Aptabase.Core which projects that don't use MAUI can use

The GitHub repository should be renamed to aptabase-dotnet following the merge of this pull request.
Maui should work... (I can't test that, I'm on Fedora Linux)

test/HelloMaui compiles on Windows 11 Pro 24H2

The core code is tested on Windows 11 Pro 24H2 and I have verified it works.

Fixes #4

[BrycensRanch]

I will add one thing though. The richness of the Maui data was decreased due to bar now being pure .NET 8. I will try and expand on the device model detection for other operating systems done the line but I believe this is a great start. If anything, Aptabase.Maui should be able to override the Aptabase.Core logic for Maui logic (design flaw?)

[BrycensRanch]

Hi, everyone! I'd like to know what I'm missing so this can get merged. I know it's a big change but it'll allow my application SnapX to use it alongside Sentry for application analytics and seeing what features are being utilized by the userbase.

[thomasgalliker]

This would be absolutly wonderful! We're about to keep old Xamarin apps alive (yeah, I know it's stupid) and we would like to use Aptabase.Core for those apps. Also, it could be used with console apps or other stuff. Make it work with netstandard2.0 and you're the heroes of many more people.

[BrycensRanch]

Hi, I can investigate net standard as a target. I am going to finish up the last of this PR & test on Windows. The only thing that’s really missing here is ensuring Aptabase.Maui still reports the same ol data as before.

[svrooij]

I want to use this in a PowerShell module (comparable with console app, target wise). Can I help somewhere to get this pr moved on?

[BrycensRanch]

This would be absolutly wonderful! We're about to keep old Xamarin apps alive (yeah, I know it's stupid) and we would like to use Aptabase.Core for those apps. Also, it could be used with console apps or other stuff. Make it work with netstandard2.0 and you're the heroes of many more people.

Hi! I did more investigation, and the dependency DotNext.Threading is only targeting .NET 8. It'd require a significant refactor to remove the dependency, and that is currently not in scope for this pull request. Now that SnapX (the project that inspired me to create this PR) has reached a state where I'm interested in how many people are testing it, I've come back to this pull request.

I know this isn't the answer you wanted, however, you should give .NET 8 a try. Big projects that use numerous Windows API calls like ShareX in less than 1k LoC. Not to mention, they get a slight no-cost performance boost. I know having clients install the .NET 8 Desktop Runtime is troublesome; that's where NativeAOT comes in.

[BrycensRanch]

I want to use this in a PowerShell module (comparable with console app, target wise). Can I help somewhere to get this pr moved on?

I've looked into this a bit more. Looks cool how you can even use .NET (Formerly known as .NET Core) in Powershell. I will give this a look! Thank you for introducing me to this use case.

[thomasgalliker]

What is the purpose of the dependencies?

• Xdg.Directories
• DotNext.Threading

I would highly recommend to remove any unnecessary dependencies in Aptabase.Core (which targets plain .NET) to keep the acceptance high.

[svrooij]

Creating an event is just one http call right?

Seeing how massive these changes are, I'll just be creating my own client and call it a day.

Will built in in net standard 2.0, meaning it will work on both .net framework and .net core

[BrycensRanch]

What is the purpose of the dependencies?

• Xdg.Directories
• DotNext.Threading

I would highly recommend to remove any unnecessary dependencies in Aptabase.Core (which targets plain .NET) to keep the acceptance high.

Xdg.Directories was added for
https://github.com/BrycensRanch/aptabase-dotnet/blob/3955993ae9d6314ddef24ca9da9fcefca55ff5c2/src/Aptabase.Core/AptabasePersistentClient.cs#L30

That replaced this MAUI-specific LoC Location = Path.Combine(FileSystem.CacheDirectory, "EventData") While Xdg.Directories can be removed, it is the most compliant implementation of trying to put files in the right location in a cross-platform way. I have just now removed the dependency.

DotNext.Threading was always an Aptabase dependency. I just moved the dependency from MAUI to the Core as it is core functionality to do with threading. (I accidentally left the reference in MAUI there, I am now committing the fix!)

[BrycensRanch]

Creating an event is just one HTTP call right?

Seeing how massive these changes are, I'll just be creating my own client and call it a day.

Will built in in net standard 2.0, meaning it will work on both .net framework and .net core

The Aptabase SDKs do slightly more than that. They create a queue of sorts. They need to handle poor internet connectivity or no network at all, and send the data later when the network is available. (Data in limbo is saved on the disk) Additionally, they "batch" requests so the Aptabase server isn't spammed with HTTP requests because of multiple events being triggered in the span of a second. I understand your frustration with the TargetFrameworks being discriminatory for such a simple solution. I can't tell you why the normal threading in .NET isn't used here.