Windows
Windows copied to clipboard
CommunityToolkit
Package id as assembly name
This PR updates our tooling to use the PackageId as the AssemblyName for components.
It required changes in both Tooling and any components with a custom PackageId due to the single-import. Hopefully this will get cleaner when we have nested components (https://github.com/CommunityToolkit/Tooling-Windows-Submodule/issues/187).
Note that any components using a custom PackageId will need to be updated to define their PackageId before importing ToolkitComponent.SourceProject.props, which requires importing the PackageIdVariant prop from MultiTarget\WinUI.TargetVersion.props first.
Prerequisite PR https://github.com/CommunityToolkit/Tooling-Windows-Submodule/pull/188
Strange, looks like this change caused new nullability warnings to appear. Investigating.
@michael-hawker Looks like the issue goes away if you use ./tooling/MultiTarget/UseUnoWinUI.ps1 3 to switch to WinUI 3, which means the internal helper is going missing when the assembly name doesn't match the root namespace.
@Arlodotexe was just thinking, is this an internal helper from another assembly or something? Did we miss an 'InternalsVisibleTo' somewhere with this change?
This is an internal helper, though I'm not sure where the helper is coming from. We need to find that before we can continue.
It looks from a search, that the helper is here (or in this file):
https://github.com/CommunityToolkit/Windows/blob/967d6c453615e0e2f9de56c2976ccfc6cc9c0008/components/Extensions/src/ArgumentNullExceptionExtensions.cs#L35
And shared with the animation package here:
https://github.com/CommunityToolkit/Windows/blob/967d6c453615e0e2f9de56c2976ccfc6cc9c0008/components/Extensions/src/CommunityToolkit.WinUI.Extensions.csproj#L32-L35
According to the docs on InternalsVisibleTo here. this sounds like it based on assembly vs. namespace, so we probably need to have a flag/choose block here to flip?
I've been trying to pinpoint why these errors are still showing.
Local repro setup Since the CI / build (WinUI2) job runs more than one TFM at a time, I opted to test Wasm since that job was also failing, but it only builds wasm.
Unfortunately, I've been unable to reproduce this error message locally building Wasm. I've tried variations of our build commands:
.\tooling\Build-Toolkit-Gallery.ps1 -Head wasm -MultiTargets wasm -Components All -Release -WinUIMajorVersion 2
and
.\tooling\Build-Toolkit-Gallery.ps1 -Head wasm -MultiTargets wasm -Components All -Release -WinUIMajorVersion 3
as well as just invoking msbuild directly, adding what's present in our build.yml.
What's happening?
My hunch is that this is still a misconfiguration with our tooling, as we've confirmed this is declared in an internal helper and not a polyfill or platform API. Checking the binlogs, the fixes in 6b54da16764f1bba12d3d1ed1280b703b2490f53 seem to be working as intended, so it's not that. Until we can repro the issue locally, what's happening here is a mystery.
A note on build times
The build time for local wasm builds has been climbing as well. It can take 15-25 minutes for a wasm release build to fully complete. However, the CI is erroring in only 2 minutes. I've been running it to completion for posterity, but for local builds we might be able to cancel the build and assume no repro after at least 5 minutes of build time.
Possible solution: https://github.com/CommunityToolkit/Windows/issues/441