Closed michael-hawker closed 2 years ago
michael-hawker
commented
2 years ago @Arlodotexe we'll see if CommunityToolkit/Labs-Windows#109 works this time, it did seem like it built even though it got stuck. So not sure why this was only appearing in Codespaces (and locally with ios?)
michael-hawker
commented
2 years ago CI script working now! But oh, right of course it works as there's only one experiment in main at the moment. How do you want to proceed? Check-in the script and then we can see if a rebased CommunityToolkit/Labs-Windows#102 fails there in the new pipeline?
michael-hawker
commented
2 years ago Ah, this is showing up in the CI now for CommunityToolkit/Labs-Windows#102 now as well: https://github.com/CommunityToolkit/Labs-Windows/actions/runs/2304895236:
Build-WinUI-2: platforms/CommunityToolkit.Labs.Droid/obj/Release/110/g/XamlCodeGenerator/GlobalStaticResources.g.cs#L56The type 'GlobalStaticResources' exists in both 'CommunityToolkit.Labs.WinUI.CanvasLayout, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null' and 'CommunityToolkit.Labs.WinUI.SizerBase, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null'
--
Build-WinUI-2: platforms/CommunityToolkit.Labs.Droid/obj/Release/110/g/XamlCodeGenerator/GlobalStaticResources.g.cs#L57The type 'GlobalStaticResources' exists in both 'CommunityToolkit.Labs.WinUI.CanvasLayout, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null' and 'CommunityToolkit.Labs.WinUI.SizerBase, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null'
Build-WinUI-2: platforms/CommunityToolkit.Labs.Droid/obj/Release/110/g/XamlCodeGenerator/GlobalStaticResources.g.cs#L62The type 'GlobalStaticResources' exists in both 'CommunityToolkit.Labs.WinUI.CanvasLayout, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null' and 'CommunityToolkit.Labs.WinUI.SizerBase, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null'
Build-WinUI-2: platforms/CommunityToolkit.Labs.Droid/obj/Release/110/g/XamlCodeGenerator/GlobalStaticResources.g.cs#L63The type 'GlobalStaticResources' exists in both 'CommunityToolkit.Labs.WinUI.CanvasLayout, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null' and 'CommunityToolkit.Labs.WinUI.SizerBase, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null'
Build-WinUI-2: platforms/CommunityToolkit.Labs.Droid/obj/Release/110/g/XamlCodeGenerator/GlobalStaticResources.g.cs#L68The type 'GlobalStaticResources' exists in both 'CommunityToolkit.Labs.WinUI.CanvasLayout, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null' and 'CommunityToolkit.Labs.WinUI.SizerBase, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null'
Build-WinUI-2: platforms/CommunityToolkit.Labs.Droid/obj/Release/110/g/XamlCodeGenerator/GlobalStaticResources.g.cs#L69The type 'GlobalStaticResources' exists in both 'CommunityToolkit.Labs.WinUI.CanvasLayout, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null' and 'CommunityToolkit.Labs.WinUI.SizerBase, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null'
Build-WinUI-2: platforms/CommunityToolkit.Labs.Droid/obj/Release/110/Resource.designer.cs#L1833The type 'Resource' exists in both 'CommunityToolkit.Labs.WinUI.CanvasLayout, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null' and 'CommunityToolkit.Labs.WinUI.SizerBase, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null'
Build-WinUI-2: platforms/CommunityToolkit.Labs.Droid/obj/Release/110/Resource.designer.cs#L1834The type 'Resource' exists in both 'CommunityToolkit.Labs.WinUI.CanvasLayout, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null' and 'CommunityToolkit.Labs.WinUI.SizerBase, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null'
Build-WinUI-2: platforms/CommunityToolkit.Labs.Droid/obj/Release/110/Resource.designer.cs#L1835The type 'Resource' exists in both 'CommunityToolkit.Labs.WinUI.CanvasLayout, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null' and 'CommunityToolkit.Labs.WinUI.SizerBase, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null'
Build-WinUI-2: platforms/CommunityToolkit.Labs.Droid/obj/Release/110/Resource.designer.cs#L1836The type 'Resource' exists in both 'CommunityToolkit.Labs.WinUI.CanvasLayout, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null' and 'CommunityToolkit.Labs.WinUI.SizerBase, Version=0.0.1.0, Culture=neutral, PublicKeyToken=null'May only be a WinUI 2 issue?
mrlacey
commented
2 years ago This is one of the issues I first saw (weeks ago) as soon as it was possible to create new experiments from the template. It's also one of the reasons I've wanted to have multiple experiments in the solution.
CommunityToolkit/Labs-Windows#102 should have been reporting this as soon as it was created. That it didn't all along is a bit worrying. (What other issues are being hidden?)
The issue is that separate libraries are created for each experiment and all are using the same namespace (CommunityToolkit.Labs.WinUI) and so when they are both referenced by the ALL sample there is a conflict because the app references multiple types (one per library) that have the same full name. This specifically happens in the Android head as there is a class generated there (for the resources) that isn't generated elsewhere.
The simplest solution is probably to change the default namespace so that it includes the name of the experiment/project. Is there any potential other side effect to doing this? It means another place to change a name[space] when migrating to the full toolkit, but these namespaces will all need changing at that point anyway.
michael-hawker
commented
2 years ago nope happens for both WinUI 2 + 3 now that all other analysis errors are cleaned up: https://github.com/CommunityToolkit/Labs-Windows/actions/runs/2305824506
michael-hawker
commented
2 years ago Talked to Jerome. This is a known Uno issue (see https://github.com/unoplatform/uno/issues/8750).
For now, we can just modify the default namespace in the csproj file? @Arlodotexe I think that'll be the simplest temporary solution.
@mrlacey we do this in the main toolkit and want to keep the pattern here just to make it easier for folks to consume multiple packages and use in code without having to have like 6 different XMLNS in their XAML or using statements in code-behind.
Changing it for now should be find as we're authoring the experiments, but it'd mean that VS would try and use it as the default namespace in new files which would break this pattern (though folders always make this problematic sometimes anyway for certain things).
Let's test out the temp change and see how things go while we're waiting on an Uno fix in the future.
michael-hawker
commented
2 years ago Tested a workaround for this in my PR, noted here: https://github.com/CommunityToolkit/Labs-Windows/pull/102#issuecomment-1124326266
Working great on the linux build. I just appended Rns for now in the ProjectTemplate so new experiments will work as well.
Once that PR is in (and uno check is fixed, that should be the last bit to do final validation), then we can close this issue and open up a new issue for tracking uno fix.
jeromelaban
commented
2 years ago Once that PR is in (and uno check is fixed, that should be the last bit to do final validation)
This change fixes uno-check, https://github.com/CommunityToolkit/Labs-Windows/pull/114. Merge or cherry-pick at your convenience :)
michael-hawker
commented
2 years ago Opened up CommunityToolkit/Tooling-Windows-Submodule#130 for tracking as we've resolved the underlying issue this issue was opened against.
Trying to run Codespaces on my CommunityToolkit/Labs-Windows#102 PR now that the source generator for documentation registry is fixed still causes this error:
Not sure what the
GlobalStaticResources.g.csfile is about. I created a new PR CommunityToolkit/Labs-Windows#109 to test running the same command on a linux environment for the CI. We should hopefully see those there as well (assuming I got the syntax right).