Checkup on the Microsoft.TemplateEngine.Cli circular dependency: dotnet/sdk -> dotnet/templating -> dotnet/sdk

Looking at v5.0.0, this package reference causes a circular dependency:

https://github.com/dotnet/templating/blob/31980633108a1bef00c798136fcd30a873c90fa3/src/Microsoft.TemplateEngine.Cli/Microsoft.TemplateEngine.Cli.csproj#L22

Circularity:

• dotnet/sdk depends on Microsoft.TemplateEngine.Cli, and produces Microsoft.DotNet.TemplateLocator.
• dotnet/templating depends on Microsoft.DotNet.TemplateLocator, and produces Microsoft.TemplateEngine.Cli.

Since dotnet/templating is “earlier” in the .NET SDK build graph (templating -> sdk -> installer), it ends up depending on an earlier version of the package than the one we actually ship. (This shows up above as dotnet/templating v5.0.0 depending on a 5.0.0-rc.1 package!)

This isn’t inherently a problem. It looks like dotnet/templating is compiling against Microsoft.DotNet.TemplateLocator for the API, but a newer version is inserted in the SDK that is actually used at runtime instead. In source-build, we can handle this by generating a ref-only version of Microsoft.DotNet.TemplateLocator/5.0.100-rc.1.20421.19 to have dotnet/templating compile against rather than having a dependency cycle.

Note that cycles do have inherent risk, this isn’t just a source-build issue. 😄 If the TemplateLocator API has breaking changes, dotnet/templating may produce a library that can’t actually run in the SDK. This is particularly risky with unstable/prerelease/rc versions of APIs.

---

A few questions about this:

1. Is this cycle intentional? (Is one of these libraries actually in the wrong repo?)
2. Can source-build rely on dotnet/templating release/5.0 always using Microsoft.DotNet.TemplateLocator/5.0.100-rc.1.20421.19, never updating?
   • Updating this causes source-build significant maintenance effort because we have to put together a new ref-only version of the package’s new version.

@vlada-shubina /cc @mmitche FYI on cycle.

[vlada-shubina]

Agreed:

• Template Engine to define ITemplateLocator interface (1 method) and IOptionalSdkTemplatePackageInfo interface and change Microsoft.TemplateEngine.Cli to use it instead Microsoft.DotNet.TemplateLocator members
• once done SDK will inject implemetation of ITemplateLocator from Microsoft.DotNet.TemplateLocator when calling TE in the shim

Since the fix is internal and not urgent, potential timeline is Q1 '21.

[vlada-shubina]

Adding @wli3

Microsoft.DotNet.TemplateLocator is used for optional workloads which are not yet live, that’s the reason probably why the version is hardcoded, as it was just used for initial implementation.

imo it is not possible to move Microsoft.DotNet.TemplateLocator to templating as it is reusing SDK features, however probably instead of calling it from Microsoft.TemplateEngine.Cli to determine packages to install/uninstall we can inject this information from sdk when instantiating new command , thus avoiding circular dependency. At first glance I don’t see any dependency on template engine for template locator to evaluate packages to install/uninstall, but I might be wrong.

Related issue: https://github.com/dotnet/templating/pull/2614