Calendars

Calendars copied to clipboard

Is MAUI version of the package planned for this great package?

I'm not aware of any changes needed for MAUI. MAUI is a replacement for Xamarin.Forms, not Xamarin itself. This package has never depended on Xamarin.Forms.

If you find incompatibility with MAUI feel free to open an issue.

(also I do appreciate the "great package" part 🙂 )

You are right! Didn't cross my mind that Xamarin NuGet can not reference any Xamarin related packages.

One thing though. Starting MAUI Android projects will be built using net6.0-android, and not MonoAndroid (same for iOS and Windows). I'm not sure, are those two compatible.

On the upside, you can use SDK-style projects with net6.0-xxx (or maybe even combine code for all platforms into a single project in VS2022).

I think, you can retarget this package to .net6 (or release a new one, it seems like most Xamarin NuGets a getting re-released for MAUI) to get advantage of new BCL, single project experience and be definitely compatible with MAUI.

Since this package doesn't get many updates and Xamarin is going away in a year, it shouldn't cause issues.

Interesting. I had been loosely following the news of MAUI and .NET 6, but sounds like this is a bigger change than I realized...

Yeah, they are unifying BCL for both runtimes (from what I understand), and more generally unifying all .Net frameworks under .netX-yyy umbrella.

From what I have seen, UI packages will be re-released under new name (that contains MAUI), since they previously contained Xamarin in there name. Re-release wil require changing all Xamarin namespaces, targeting .net6-XX instead of MonoAndroid, Xamarin-iOS, etc. And rewiring deprecated code that (mainly related to renderers)

As for non-UI packages like yours, I'm not sure (haven't seen many). But I think simply targeting .net6 should do it.

Here's some more info: https://www.youtube.com/watch?v=xGIkGX2FXPE

Update

I created a MAUI sample app running .Net 6 Preview 6 using those commands:

dotnet new --install Microsoft.Maui.Templates::6.0.100-preview.6.1003
dotnet new maui -n HelloMaui

• Release APK size without this NuGet: 16,023,177 bytes
• Release APK size with this NuGet (and code that uses it): 16,058,149 bytes

Also tested that NuGet works, and it does, so it looks like no migration is necessary! (at least if they don't change something before releasing MAUI)

You can migrate to .Net 7 in a year when support from Xamarin would end just to take advantage of new SDK with new language features.

Great, thanks for the update!

Also this could be used to run Android and iOS tests in CI after migrating to .net6: https://github.com/dotnet/xharness It's currently used in https://github.com/dotnet/runtime

I think there is an update required to support windows, as with MAUI it does not target UAP anymore (as it is WinUI 3 based).

When using the library I get an exception that the platform-implementation is missing as it seems to take the NETSTANDARD version for the windows-build instead of the UAP one...

...building the UWP code against net6.0-windows10.0.19041.0 seems to be working.

Looks like .net6 migration will be needed after all. Haven't tested myself, but turns out there's no backwards compatibility on iOS:

• https://github.com/dotnet/maui/discussions/1743#discussioncomment-1923598
• https://github.com/dotnet/designs/blob/main/accepted/2021/net6.0-tfms/net6.0-tfms.md#design

Thanks @maxkoshevoi for the info. I'm guessing/hoping that just means adding a new project that targets .net6-ios and references the same code as the Xamarin.iOS project...?

@chrfin When you say "building the UWP code against...", are you referring to changes you made to your own project, or saying that you had to pull the code for this project and modify/rebuild it to get it to work? If the latter, PRs are welcome. 🙂

@TheAlmightyBob I had to take your code and add a net6.0-windows10.0.19041.0 TFM using the same code as the UWP TFM. But net6.0-android and net6.0-ios did work with the original package. 

I only use my "custom build" for the windows implementation and your package for the shared code and the other two. (I named my assembly Calendars.Plugin.UWP.Tests to access the internal methods).

@TheAlmightyBob as mentioned in the article above, net6.0-ios project cannot reference Xamarin.* projects. You can add net6.0-ios as a new TFM, but it's better to retarget whole NuGet to net6 targets (MAUI releases sometime around May, and Xamarin won't be supposed anyway)

@TheAlmightyBob @maxkoshevoi I did a quick try and was able to build all versions against the appropriate .NET6/MAUI-TFMs - please see my PR #85. Going forward this should be done differently I guess, but for a first feature-equivalent version this could already work.

@chrfin How about droping support for all non-net6 TFMs? And mark this next version as pre-release in case there're any bugs.

I don't see any point in supporting them further. And I haven't seen any MAUI package that targets anything except net6;net6-*. Leaving only net6 targets would make code simpler.

As soon as there are code-changes I would also drop Xamarin support, but as long as it works, why drop something working 🤷‍♀️...

Or after MAUI is GA drop it, but for now it could be done this way.

But I'm fine with drop+pre-release also...

why drop something working

Previous versions of the NuGet wouldn't go anywhere. IMHO it's better to retarget NuGet to net6 only TFMs to use newer SDK (better nullability detecting, simpler project structure, SDK-style project files, etc.); release new version as pre-release, and release it when MAUI goes GA

Xamarin version of the repository can be moved to some legacy branch, so that it still could be updated (I doubt that any updates will be needed, since there weren't any for a while, and Xamarin wouldn't be supposed for much longer)

First off, greatly appreciate the activity/discussion here. It'll take me some time to catch up, but I'm not ignoring this, just busy and out-of-the-loop on MAUI/net6.

I'll say that my own bias is like @chrfin said, "why drop something working." As I had suggested above, I had assumed that the straightforward approach would be to add new projects that reference the existing files and then corresponding new <file> entries in the nuspec to map them accordingly. @maxkoshevoi , you keep speaking of "retargeting NuGet to net6 only". I don't think I understand what exactly that means or what the benefit is. As far as I understand, a NuGet is just a collection of different files for all sorts of different targets... why would it matter for it to have both "legacy" and net6 targets in it? Is there some new type of net6 NuGet?

The pre-release approach isn't crazy, but it's also not quite trivial (at least, AppVeyor makes it more annoying to do prereleases than I would like..)

I'm also not certain what the experience would be, if this was then fully released as net6-only, for somebody still using Xamarin (as I expect many will not rush to immediately migrate to net6)... would NuGet know to show them the most recent version that still supported their target frameworks? Or would it just look like they can't use this library? (I know you can manually select older versions on NuGet, but you'd have to know that a previous version was still compatible)

I had assumed that the straightforward approach would be to add new projects that reference the existing files and then corresponding new <file> entries in the nuspec to map them accordingly

Oh, "reference files", sorry, I'd completely misread your original comment. Yes, this does work, as demonstrated by @chrfin in his PR.

you keep speaking of "retargeting NuGet to net6 only". I don't think I understand what the benefit is

No benefit for the end user. It would just make this repository much simpler (only one src project instead of four, and possibly also single test project, but not sure about that one). But yes, for NuGet consumers it's better if NuGet would support as many TFMs as possible.

The pre-release approach isn't crazy, but it's also not quite trivial

I'm insisting on pre-reliase cause MAUI likes to break stuff. For example, projects that are built with MAUI Preview 11, cannot reference NuGets that are dependent on MAUI Preview 10 or lower: https://github.com/dotnet/maui/issues/3965

But I think, it would be ok to release net6 version of this NuGet as a stable version, if it wouldn't be dependent on MAUI (which it shouldn't anyway)

Ok, I withdraw my argument for dropping older TFMs. Found another NuGet that keeps them as well: https://github.com/jamesmontemagno/InAppBillingPlugin/pull/436#discussion_r783517320

I think people are dropping older TFMs if they are creating new NuGet from MAUI. If NuGet stays the same (only version changes), maybe it's better to keep support for all TFMs.

Thanks for inquiring about and linking the InAppBillingPlugin. Good to see examples of other plugins dealing with this... although that's another that lacks a nuspec... apparently you can put all that stuff in the csproj now? Interesting...

If this was a new project, or was a UI thing that interacted with Xamarin.Forms/MAUI in some way, I could see that supporting older targets might not seem worthwhile. But yeah, this library never had any dependency on Xamarin.Forms and I wouldn't expect it to have one on MAUI. It's just the .NET6 part that's of interest...

(as an aside, however, it's curious to me that James updated his readme to say that it supports ".NET MAUI" and "Xamarin"... my understanding is that "MAUI" is only the name for the new cross-platform UI abstraction replacing Xamarin.Forms, not the name for a .NET6 app targeting the native iOS/Android APIs... am I mistaken? Or is MAUI more just the hot new thing to advertise?)

And re: making the repository simpler, yeah that would be nice, but this repository used to have even more targets for different platforms (Windows Phone & iOS "Classic"), but because those projects could all reference the same code files I don't think it was a big deal. (just the annoyance of more platforms to consider & test on when making changes)