Skip to content

Navigation Menu

Sign in

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

CsWinRT 2.0 and .NET 5 #1232

manodasanW announced in Announcements
CsWinRT 2.0 and .NET 5 #1232
@manodasanW manodasanW
Aug 1, 2022 · 3 comments · 9 replies
Return to top
Discussion options

manodasanW
Aug 1, 2022
Maintainer

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.
You must be logged in to vote

Replies: 3 comments · 9 replies

Comment options

michael-hawker
Aug 1, 2022

FYI @azchohfi @Sergio0694
You must be logged in to vote
0 replies
Comment options

Sergio0694
Aug 2, 2022
Collaborator

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? 😄
You must be logged in to vote
8 replies
@dotMorten
Comment options

dotMorten Aug 11, 2022

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
Comment options

dotMorten Aug 11, 2022

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
Comment options

manodasanW Aug 13, 2022
Maintainer Author

@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
Comment options

sylveon Aug 27, 2022

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
Comment options

hez2010 Sep 2, 2022

@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.
Comment options

jlaanstra
Aug 15, 2022
Collaborator

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()?
You must be logged in to vote
1 reply
@manodasanW
Comment options

manodasanW Aug 16, 2022
Maintainer Author

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
7 participants
@manodasanW @dotMorten @jlaanstra @sylveon @Sergio0694 @hez2010 @michael-hawker
Morty Proxy This is a proxified and sanitized view of the page, visit original site.