[Submodule] Issues for submoduling infrastructure
- [ ] #15 Global Usings files should be replaced with props file versions to minimize needing to include files in each project, more transparent. for instance, this is a problem currently:
https://github.com/CommunityToolkit/Labs-Windows/blob/3ab75baf6a3246cf9a1891488dbcb52189a64c7e/Windows.Toolkit.Common.props#L33-L35
- [ ] Find a better home for certain things like this:
https://github.com/CommunityToolkit/Labs-Windows/blob/3ab75baf6a3246cf9a1891488dbcb52189a64c7e/Directory.Build.targets#L21-L26
-
[ ] In fact do we need the base props/target files since we have our projects include a common file as a starting point, can we just move all these things (or most of them elsewhere?) - At least maybe for props. Like we should probably just have the Directory.Build.props be the common project info like we have in
Windows.Toolkit.Common.props. -
[ ] Document which things need to exist for the sub modules to work (like
RepositoryDirectorydefinition)
- [ ]
global using CommunityToolkit.Labs.WinUI;is in the GlobalUsings_WinUI file, but if we don't use that namespace, then it's a compile error. - [ ] TKSMPL0014 is a warning (no sample in doc), but then I don't think it generates the registry? So then compile error... maybe just a case where we have zero samples which shouldn't happen, but we should probably safeguard in case we see a scenario where someone just uses docs in an app shell or something...
- [ ] Noticed this YAML error, think has to do with 'TODO:' note maybe?

- [ ] In addition to
commonandtemplatefolders, need to document need for putting things incomponentsfolder as well as the need for the.config/dotnet-tools.jsonfile. (probably just create a template repo?)
- [ ] GenerateAllSolution fails if a component doesn't have a src folder:
common\MultiTarget\GenerateAllProjectReferences.ps1:21 char:14
+ $srcPath = Resolve-Path "$($projectPath.FullName)\src";