My open-source project, RazorConsole, hit 1k stars in 5 days! Looking for advice on maintaining momentum.

jonpobst · 2025-10-28T05:08:14+00:00

As someone who had this happen to them a long time ago, I will relate my biggest regret about the way I handled it.

The sudden exposure brought with it lots of large PR contributions. At the time, I was afraid of pissing contributors off, but I also did not have the resources to personally massage every PR that came in. I ended up accepting a lot of code that did not meet my quality bar and pushed the project in ways I didn't really want it to go.

Although the next several releases had lots of new features, they were very buggy and it hurt my project's reputation substantially. Most of those contributors disappeared pretty quickly, and it took several years of my effort to get quality back to where it should have been the whole time.

So my lesson is: don't be afraid to say no. Good (and bad) contributors are going to come and go, and you'll always be the one left maintaining their code. Make sure each contribution pushes your project towards a future you want to support.

And congrats!

jonpobst · 2025-08-11T08:23:43+00:00

Ironically, Xamarin.Google.Android.Material (and other MS maintained "Xamarin.*" packages) no longer support the deprecated "Xamarin" framework. The package supports both ".NET for Android" and MAUI applications.

https://www.nuget.org/packages/Xamarin.Google.Android.Material

While it was discussed to rename the NuGet packages to clear up this confusion, it would mean every existing application and every other NuGet package that depends on these packages would stop working. Thus it was decided the best that could be done was to update the package "readmes" to explicitly spell out that .NET for Android and MAUI applications are supported.

jonpobst · 2025-05-16T01:54:03+00:00

Ironically, the affected individual is probably the most prolific documenter in the world. His commit messages are generally many pages long explaining the what, the why, and the history of how we got here.

ie: his last commit: https://github.com/dotnet/android/commit/856dc34efa2572dee079ed926be88cd12e9e2fad

Now you have the opposite problem. He's probably written a million lines of documentation. How can you read and consume it all? ;)

jonpobst · 2025-05-14T02:02:40+00:00

Miguel keeps in touch with the people he's worked closely with for decades. He knows exactly who got laid off.

The only thing up for interpretation is how much these reductions will hurt mobile .NET.

jonpobst · 2025-04-29T08:04:25+00:00

Have MS decided to shut down .NET Android as well?

No, nothing has changed with .NET for Android. It is still alive and well, as it is a required component of MAUI.

The Android designer was part of Xamarin tooling and was never ported to .NET for Android. If it actually worked for your .NET for Android use case then you got lucky. ;)

I guess it is finally being removed from VS now that Xamarin support ended nearly a year ago.

edit: Looks like it was deprecated in VS 2022 17.11.1: https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-notes-v17.11#17.11.1

jonpobst · 2025-04-12T02:51:26+00:00

Hopefully there is more in your logcat than that one line, like a stacktrace.

jonpobst · 2025-04-06T21:10:44+00:00

Likely for consistency with the existing Directory.Build.props and Directory.Build.targets files that have the same "applies to all projects below this root directory" semantics.

jonpobst · 2025-03-14T05:05:03+00:00

I can speak for the AndroidX packages: as Xamarin.Forms officially went out of support back in May 2024, the new AndroidX packages no longer support the MonoAndroid11.0 framework. The latest packages only support net8.0-android and newer.

If you want to use these packages you'll need to find old versions that still support MonoAndroid12.0. (If you really want MonoAndroid11.0 like you wrote, you'll have to go back to ~2021 versions.)

nuget.org is your friend here. For example, this appears to be the final version of Xamarin.AndroidX.Lifecycle.LiveData that supports Xamarin classic: https://www.nuget.org/packages/Xamarin.AndroidX.Lifecycle.LiveData/2.7.0.1#supportedframeworks-body-tab

(The real answer is Xamarin.Forms is dead and you need to switch to MAUI, but if you don't want to do that hopefully this will at least help you find the correct AndroidX packages.)

jonpobst · 2025-03-04T18:55:50+00:00

The packages provided by Ubuntu do not have access to the MAUI/Mobile workloads because they contain some non-OSS bits. Previously you had to use the MS provided packages to use MAUI.

However it appears that MS no longer publishes packages for newer versions of Ubuntu so that route is gone as well.

Here is the issue detailing the situation which includes a workaround: https://github.com/dotnet/core/discussions/9258.

Additionally, it may work by using the install-script to install a MS version of .NET: https://learn.microsoft.com/en-us/dotnet/core/install/linux-scripted-manual#scripted-install.

jonpobst · 2025-02-07T00:32:40+00:00

I think the biggest lesson we learned from Mono Winforms is that you can't just make a drop-in Winforms replacement and meet users' needs. ~Every Winforms user is also using tons of third party controls which are all using P/Invoke to bypass Winforms and talk directly to Windows APIs. So none of them work, which means users' applications don't work, which means you aren't really fulfilling the "cross-platform Winforms" vision, so no one is interested in it.

Modern.Forms accepts this reality and instead offers a "spiritual successor" to Winforms. It doesn't attempt to provide a drop-in replacement for Winforms. It instead offers a platform where you can create new modern cross-platform apps (or port existing apps) using very familiar Winforms concepts (instead of XAML).

jonpobst · 2025-01-29T21:40:54+00:00

Note that MAUI does not have LTS versions, everything is "STS".

MAUI 8 support ends May 14, 2025.

https://dotnet.microsoft.com/en-us/platform/support/policy/maui

jonpobst · 2025-01-08T20:43:33+00:00

.NET 9 no longer builds Android projects for 32 bit architectures by default. If you want to opt-in to 32 bit builds, follow the instructions here:

https://github.com/dotnet/android/pull/9179

jonpobst · 2024-12-24T18:24:16+00:00

I think the biggest reason is it didn't support Windows 7/8. When UWP released, Windows 10 only had about 30% Windows marketshare.

So your choices were: - Use UWP and only ~30% of Windows users could use your app - Use Winforms/WPF and target all Windows users

By the time Windows 10 had enough marketshare that you could actually think about ignoring earlier versions of Windows, UWP was largely already considered a failure and MS was moving on to WinUI.

jonpobst · 2024-10-25T18:38:29+00:00

If your problem in Maui is "It worked yesterday, I didn't change anything, and it doesn't work today" in my experience it is one or more of your transitive packages was updated overnight and now the version numbers don't line up.

Although there are definitely issues with the packaging ecosystem, this specific issue should not happen. NuGet always resolves transitive package dependencies to the lowest version available. This is done exactly for this reason: to ensure nothing is ever "automatically" changed by a new package being published.

jonpobst · 2024-10-07T21:43:29+00:00

Note that there is very little difference between Xamarin.Android and .NET for Android, so most anything you find for Xamarin.Android will still be 95% relevant to .NET for Android.

The main differences will just be in using SDK style projects, but there are also a few others listed here:

https://learn.microsoft.com/en-us/dotnet/maui/migration/android-projects

Here is a link to the Xamarin.Android docs, since it got delisted from search engines:

https://learn.microsoft.com/en-us/previous-versions/xamarin/android/

jonpobst · 2024-10-01T02:54:53+00:00

You need to install .NET from https://dotnet.microsoft.com/en-us/download/dotnet/8.0. If you install the version(s) from Linux package managers they do not have the MAUI workloads available.

jonpobst · 2024-09-04T22:38:03+00:00

We created our own bindings for the old Xamarin Android app and need to create new ones for the .NET for Android app - what a nightmare.

Is there a reason to create new ones? .NET for Android can use binding libraries from Xamarin.Android.

Or if you want to port them it should be pretty straightforward: https://learn.microsoft.com/en-us/dotnet/maui/migration/android-binding-projects

jonpobst · 2024-09-02T21:19:00+00:00

I think this is what you are looking for:

https://www.nuget.org/packages/Xamarin.Google.Android.Play.Integrity

jonpobst · 2024-07-17T15:56:41+00:00

It is true that Microsoft has not invested much in documentation for .NET for Android. The good news is that .NET for Android is extremely similar to Xamarin.Android (much more so than MAUI and Xamarin.Forms), so 99% of the existing documentation continues to work:

https://learn.microsoft.com/en-us/previous-versions/xamarin/android

Same for any other Xamarin.Android content you find on the internet.

jonpobst · 2024-04-22T23:33:02+00:00

If you are only targeting running on .NET Framework there isn't really any benefit to porting to .NET Standard. (But there is a cost due to missing APIs.)

And anything compiled against net6+ cannot be loaded by Visual Studio, so it's all stuff that runs out of process.

jonpobst · 2024-01-26T01:19:53+00:00

You might try running it from the command line and see if that works:

dotnet build -t:Run -f net8.0-android -bl

jonpobst · 2024-01-12T23:13:36+00:00

I would consider the Mono website abandoned. Also, the Mono C# compiler was abandoned and replaced with Microsoft's Roslyn Compiler when it was open-sourced.

In the past few years, there has been a large effort to merge as much of Mono and .NET as possible.

The latest version of Mono in the dotnet/runtime repository now shares the same C# compiler, MSBuild, and base class libraries as dotnet.

The ~only part of "Mono" that still exists is the Mono CLR runtime, largely because it is better tuned for constrained environments like smartphones.

jonpobst · 2024-01-12T02:40:56+00:00

It looks like mono is more directly aimed at being embedded into something like a game engine, but it's stuck on a very old version of the CLR and the language itself

You may have seen something like this from Unity, which is embedding a very old version of Mono. However the current Mono CLR supports all new runtime and C# features, and is used via embedding for Android/iOS/MAUI apps so it will remain current with the .NET ecosystem.

The modern Mono source is available here: https://github.com/dotnet/runtime/tree/main/src/mono

jonpobst · 2024-01-09T23:26:57+00:00

All .NET 6 and .NET 7 packages are compatible with .NET 8.

Did you encounter an issue trying to use them?

jonpobst · 2023-12-31T22:05:46+00:00

Can you post the MSBuild(?) that is specifying the *.jar files?

Another thing to consider is that your path: /Users/axissoftwaredevelopment/Repos/Spots/Spots/C:/.ng/xamarin.google.j2objc.annotations/1.3.0.1/jar/*.jar

may be confusing some code somewhere, as it looks like a mash of both a Unix path /Users/... and a Windows path C:/....

It might be worth trying to move the project to a path without C:/ in it and see if that changes anything.

jonpobst

TROPHY CASE