Remove the need for GuidGenerator/IIDOptimizer for all ABI interfaces.

[jlaanstra]

This PR generates ReadOnlySpan for guids for all ABI types which can then be efficiently passed to QI methods by doing MemoryMarshal.Read<Guid>(span).

The C# compiler since .NET7 optimizes the byte array to a readonly data section as it sees that there are no ways the byte array can be changed, resulting in less byte arrays created.

There are a few places left with this PR where generics can show up and we need to decide how we generate IIDs for those, for example IList.

[jlaanstra]

/cc @jkoritzinsky

[jkoritzinsky]

Instead of exposing ReadOnlySpan<byte> at the APi level. Can we make the span member a private static and make a public Guid property that just returns new Guid(span)?

[jlaanstra]

Instead of exposing ReadOnlySpan<byte> at the APi level. Can we make the span member a private static and make a public Guid property that just returns new Guid(span)?

We could but copying a span around is cheaper I think? This is all internal to the projection code anyway.

Nevermind, new Guid(span) should do the same thing.

[manodasanW]

Given this is an API surface change, can I get you to retarget this PR to staging/AOT which is the branch I am treating as the staging branch for our next assembly version increment.

[jlaanstra]

Given this is an API surface change, can I get you to retarget this PR to staging/AOT which is the branch I am treating as the staging branch for our next assembly version increment.

It's not breaking though? I can retarget but that also retargets the factory caching PR.

[manodasanW]

Given this is an API surface change, can I get you to retarget this PR to staging/AOT which is the branch I am treating as the staging branch for our next assembly version increment.

It's not breaking though? I can retarget but that also retargets the factory caching PR.

Right, it is not breaking but anyone moving to this version of CsWinRT to generate their projection will probably need to update all their dependent projections to ones that has these changes. So, they at a minimum will need the updated Windows SDK projection, which will need to increment its assembly version, and possibly other dependent projections based on the APIs being projected. We try to minimize how often we do such changes by grouping them together.

If the factory caching PR is dependent on this, we can mitigate the assembly version impact on that PR by only doing it for exclusive interfaces (i.e includes factory interfaces) rather than all. And then having the PR in the staging/AOT branch do it for all.

[jlaanstra]

Given this is an API surface change, can I get you to retarget this PR to staging/AOT which is the branch I am treating as the staging branch for our next assembly version increment.

It's not breaking though? I can retarget but that also retargets the factory caching PR.

Right, it is not breaking but anyone moving to this version of CsWinRT to generate their projection will probably need to update all their dependent projections to ones that has these changes. So, they at a minimum will need the updated Windows SDK projection, which will need to increment its assembly version, and possibly other dependent projections based on the APIs being projected. We try to minimize how often we do such changes by grouping them together.

If the factory caching PR is dependent on this, we can mitigate the assembly version impact on that PR by only doing it for exclusive interfaces (i.e includes factory interfaces) rather than all. And then having the PR in the staging/AOT branch do it for all.

I don't think that's true? You could just do this for one projection and it should work fine, since it is only done for types internal to the current projection?