CsWinRT 2.0 and .NET 5

[manodasanW]

With .NET 5’s end of support on May 10, 2022 , the Windows SDK projection brought in by the .NET 5 SDK is no longer updated. .NET 6 and later SDKs continue to be updated. With CsWinRT bringing in new features such as IL trimming, the generated projections are starting to use APIs that are only available in or can only be guaranteed to be available in applications targeting .NET 6 and later. Due to this, CsWinRT plans to drop support for .NET 5 and move to CsWinRT 2.0. CsWinRT 1.6.5 will be the last update which supports .NET 5 and any customers who still need .NET 5 compatible projections may continue to use it.

[michael-hawker]

FYI @azchohfi @Sergio0694

[Sergio0694]

Does the 2.0.0 version indicate (as per semantic versioning) that it will have the liberty of making some breaking changes and correct some unfortunate design decisions of the first release, and improve the API shape in general? Just to make a few random examples:

Having ConcurrentDictionary<TKey, TValue> (and 2 of them) in the public API surface of IWinRTObject:

CsWinRT/src/WinRT.Runtime/IWinRTObject.net5.cs

Line 153 in a59ba54

protected ConcurrentDictionary<RuntimeTypeHandle, IObjectReference> QueryInterfaceCache { get; }

CsWinRT/src/WinRT.Runtime/IWinRTObject.net5.cs

Line 169 in a59ba54

ConcurrentDictionary<RuntimeTypeHandle, object> AdditionalTypeData { get; }

Function pointers in IUnknownVtbl from using a managed signature and causing a marshalling stub to be generated:

CsWinRT/src/WinRT.Runtime/Interop/IUnknownVftbl.cs

Lines 17 to 22 in a59ba54

	private void* _QueryInterface;
	public delegate* unmanaged[Stdcall]<IntPtr, ref Guid, out IntPtr, int> QueryInterface { get => (delegate* unmanaged[Stdcall]<IntPtr, ref Guid, out IntPtr, int>)_QueryInterface; set => _QueryInterface = (void*)value; }
	private void* _AddRef;
	public delegate* unmanaged[Stdcall]<IntPtr, uint> AddRef { get => (delegate* unmanaged[Stdcall]<IntPtr, uint>)_AddRef; set => _AddRef = (void*)value; }
	private void* _Release;
	public delegate* unmanaged[Stdcall]<IntPtr, uint> Release { get => (delegate* unmanaged[Stdcall]<IntPtr, uint>)_Release; set => _Release = (void*)value; }

The IObjectReference type exposing a protected bool field:

CsWinRT/src/WinRT.Runtime/ObjectReference.cs

Line 25 in a59ba54

protected bool disposed;

Or is 2.0.0 just to indicate the fact .NET 5 is being dropped? ...I hope it's the former? 😄

[dotMorten]

I'm a bit sad to hear that.

But I'm happy to hear that. As a 3rd party vendor I can't keep playing catchup to breaking changes - especially not to a platform that doesn't have a huge customer base currently - Something like that could cause us to drop support if we find it too unstable and cost-prohibitive to continue to support.
I'd rather that instead of defaulting to "lets break everyone", they took at look at providing an alternative to the things that are blocking you.

Perhaps some of the new NET7 stuff that can do better blitting and remove the need for stub generation in the interop will address that specific issue?

[dotMorten]

Honestly just dropping .NET 5 might have been done in a minor release as well.

I think that's a fair point. After all that's what WinAppSDK is doing too.

[manodasanW]

@Sergio0694 I looked at where we make use of the QueryInterface function pointer from IUnknownVftbl and all of it uses seems to be within WinRT.Runtime and is not used directly in any of our generated projections. Due to that, I believe we should be able to address that concern without breaking any existing projections or consumers of those projections.

[sylveon]

The real question is how would this affect downstream? Ie WinAppSDK takes a dependency here and also gets a breaking change, in addition to all 3rd party class libraries that takes a dependency on that. I’d thread VERY lightly with introducing any breaking changes beyond the tfm change - the ecosystem is still trying to catch up to WinAppSDK and I honestly don’t think they can afford to break people.

WASDK has happily broken C++ users in minor releases before, so the ecosystem is already dealing with breaking changes. What's one more breaking change to the list?

[hez2010]

@manodasanW
Actually we consider WASDK 1.2 with CsWinRT 2.0 to be the first usable version of WinUI 3 apps, because it's the first version that aligns WinUI 2.8 styles and supports IL trimming, and also, the first version that doesn't support net5.0.
I think once we miss the chance of making breaking changes in CsWinRT 2.0, it will be much harder to do so in the future.

[jlaanstra]

Thoughts on getting rid of the As* methods as part of 2.0 and do the mapping automatically like we already do for IIterable->IEnumerable, IVector ->IList, Uri->Uri etc? Few examples that come to mind:

• Automatically mapping Task and Task to IAsyncOperation/IAsyncAction without the need for AsAsyncOperation()/AsAsyncAction()?
• Autmatically mapping stream types without the need for AsStream()/AsRandomAccessStream()?

[manodasanW]

It is an interesting idea to do a custom type mapping for Task and Streams (it is a bit more involved than the others), but for 2.0 we are avoiding changes that can break compat with existing projections or their consumers.