Support SDK generation outside Azure/azure-sdk-for-net

[heaths]

With goals of becoming more of a toolset, we need to support building - but not necessarily shipping; we'll still be the authoritative, official source of client libraries - SDKs outside our repo. This is related to our efforts with code generation atop TypeSpec, both for generating server source as well as client source - the latter of which would be used for testing the service and giving the service team an early preview of what using their SDK would look like so they can make adjustments to their TypeSpecs as needed.

Currently, I can think of the following issue(s) that prevent us from supporting this:

• Shared source: we have a lot of shared source that we link into our SDKs, and paths are found relative to our repo layout. Alternatively, we could consider:
  • Put it in an obvious namespace like "Azure.Internal" or something (ASP.NET does something similar) but make the types public. This is also a common approach in most other track 2 languages.
  • Publish a separate "source package" kin to Azure.Core but containing only shared source. IIRC, we did (or still do) something like this with autorest.csharp.
• Azure.Core.TestFramework relies on <ProjectReference> but we could publish this and use a <PackageReference> instead. License and description could specify it's only in support of developer Azure SDKs, or perhaps we publish it to an internal feed if we're not ready to completely open it up.

[heaths]

We discussed this in our team sync yesterday, and it turns out we already have something in place. I think it's a good start to unblock internal partners but, long-term, we'll need to consider other options to make this accessible to the public e.g., outside contributors or third-party partners.

Available now

• If the namespace in tspconfig.yaml starts with "Azure." the right template is chosen to pull in shared source as we would within the repo today. This lacks many - if not all - of the analyzers we'd run in our repo, however, but should produce an SDK that is the same or very similar to what we'd ship from our repo when the time came.
• There are allegedly some scripts or tasks that will make a shallow clone of our repo, generate the necessary project files and source, and build an SDK as if it were done in our repo from the start. These may be the same tasks that we use in the Azure/azure-rest-api-specs repo. Need to investigate further.

Long-term

• We could create a "lite" assembly of build files that we have in our repo now - ideally, we'd use those in our build for qualify control and consistency - and could package those up and publish the package to our public Azure Artifacts feed, which we already point to in our root nuget.config file. This could run the appropriate analyzers, build validations, etc., and potentially enforce the same package dependency we have now in eng/Packages.Data.props.