Investigate Template Parameters

[michael-hawker]

Investigate if the https://github.com/dotnet/templating system allows us to pass in parameters to modify the generation.

Default would still be everything included.

We'd want to have a flag which can either:

• remove the templated control added in CommunityToolkit/Labs-Windows#157 CommunityToolkit/Labs-Windows#160
• generate a .NET Standard source library/unit test project instead (remove PackageIdVariant and MultiTarget lines from csproj)

[Arlodotexe]

(remove PackageIdVariant and MultiTarget lines from csproj)

note that removing PackageIdVariant complete will result in a package name CommunityToolkit.Labs..ProjectName.

If we're removing it instead of replacing, that will need to be fixed in the .csproj. Should be doable with built-in msbuild string checks.

[michael-hawker]

@Arlodotexe yes, I mean we'd modify the csproj file to remove that and the dot vs. trying to do it automatically.

I imagine in the template we'd have something like:

#if <template parameter for dotnet project in whatever special syntax this is>
<PackageId>CommunityToolkit.Labs.ProjectTemplate</PackageId>
#else
<PackageId>CommunityToolkit.Labs.$(PackageIdVariant).ProjectTemplate</PackageId>
#endif

[mrlacey]

This should be fairly straightforward. Just need to determine what needs to be optional.

Is there an issue related to the work that will necessitate this?:

generate a .NET Standard source library/unit test project instead (remove PackageIdVariant and MultiTarget lines from csproj)

For reference:

• https://github.com/dotnet/templating/blob/main/docs/Conditions.md
• See also the Uno templates that already use parameters (example)

[michael-hawker]

Cool, so doesn't look like we could do an explicit directive in a csproj file, but there is config in the json to swap out specific files or directories based on the condition, so that's good to know.

The .NET Standard stuff came out of the meeting this morning and talking more about how the repo could support general .NET helpers vs. WinUI specific stuff. It's definitely a more future facing part of this, but certainly something that would need to be more clearly defined.

I think the main changes would be when enabled:

• CommunityToolkit.Labs.TemplateProject.csproj would be used instead of CommunityToolkit.Labs.TemplateProject.WinUI.csproj
  • It shouldn't need MSBuild.Sdk.Extras (I think)
  • This wouldn't include the Labs.MultiTarget.props file
  • I believe we could remove the <RootNamespace> change.
  • It'd have <PackageId>CommunityToolkit.Labs.ProjectTemplate</PackageId> instead
  • The extra XAML ItemGroups would be removed
• The Tests folder heads would not have the UWP or WinAppSDK one, but a standard single .NET 6 one. (I think the all solution aggregate would only pull them into the WinAppSDK head though maybe or we could separate that out for this as another run?)

@Arlodotexe I know shared projects aren't ideal, but I think we'd still want to have it setup that way for consistency with other experiments? Anything else I miss?