Remove legacy TFMs

[Redth]

The legacy TFM's are not helpful at this point anyway, so removing them may make things less confusing to not have multiple projects. This helps omnisharp parse things better too.

I've added an omnisharp.json file to exclude some projects/files from loading...

However, roslyn still loads a .sln file, so I've added _omnisharp.sln. It's not obvious which 'first' .sln it finds, in testing sometimes the _omnisharp.sln was found first, other times, one within Compatibility was - there's no way seemingly to control which one to load first. So, we could rename the sln to Microsoft.Maui-vscode.sln or something similar if anyone objects to the current name I used.

Once you do load a .sln (you can tell vscode which one to use and omnisharp will re-evaluate things), it will factor in the config file's excludes.

This makes vscode much faster to use on macOS in particular.

Update

Removed all net6.0 versioning from .targets/.props checks, and .csproj's (except templates because those need to have the right TFM though we can probably make that a variable too). This will help make it easier to build against net7.0 and future versions.

This consolidates also now the platform identifier checking, and uses a property msbuild function $([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramewrok)') to assign the platform in a property in Directory.Build.props so that it's available to use everywhere (along with some platform properties like _MauiTargetPlatformIsAndroid).

Finally, it also removes some old msbuild logic that's now unnecessary.

[Redth]

If there's an easy better way, we can update this right away before merge, but leaving the hack that seemed to work from before for now.

[eerhardt]

Is there any reason we are still building for netstandard2.1;netstandard2.0? I would assume that Maui only needs to build for net6.0 going forward.

[jonathanpeppers]

This assembly gets loaded by MSBuild (.NET Framework in VS), so that is why we have netstandard2.0.

I'm not sure why we'd have netstandard2.1, though?

[eerhardt]

For reference, WinForms only builds for the "current" .NET TFM:

https://github.com/dotnet/winforms/blob/f52d095a67eb0e9d60539dbd1b09da1e26ef3c29/Directory.Build.props#L9-L11

Same for asp.net:

https://github.com/dotnet/aspnetcore/blob/b89eba6c3cda331ee98063e3c4a04267ec540315/src/DefaultBuilder/src/Microsoft.AspNetCore.csproj#L4
and
https://github.com/dotnet/aspnetcore/blob/9d6f7e3b2b7eb12abc3a656827545a4ceb2ce090/eng/Versions.props#L44

Same for wpf:

https://github.com/dotnet/wpf/blob/d52d2474b7a611ea2cb23ab3370147fff0c03dc9/Directory.Build.props#L5

[eerhardt]

This assembly gets loaded by MSBuild (.NET Framework in VS)

Really? Why?

[pranavkm]

MSBuild task?

[jonathanpeppers]

The "XamlC" MSBuild task, and maybe others, use some of the core types. It's possible this could be reworked, but this was the same in Xamarin.Forms.

[chucker]

The legacy TFM's are not helpful at this point anyway

This seems to have removed net6.0-macos support from MAUI Essentials. While MAUI itself doesn't support macos¹, .NET 6.0 does (including UI support), Xamarin Essentials did work for macOS targets as well, and the UsingMauiEssentials property exists to use MAUI Essentials outside MAUI.

So, for example, Preferences can wrap NSUserDefaults across most Apple platforms; it seems like a mistake to remove support on macos for that.

Footnotes

1. it supports maccatalyst, which is distinct. ↩

[jonathanpeppers]

@chucker there was never a maui-macos workload, how were you actually using Essentials there?

[chucker]

how were you actually using Essentials there

I wasn't, not in MAUI.

But the blog post introducing Essentials implies that this replaces Xamarin Essentials, and in a Xamarin.Mac project, those did work fine for me, so I figured this project was the replacement when migrating to net6.0-macos.

[jonathanpeppers]

@chucker I'd recommend just filing a new issue titled "Essentials support for net6.0-macos", so that folks can upvote it.