Add support for deploying dacpacs from referenced NuGet packages

[jmezach]

Closes #327

This adds support to the SQL Database Projects integration to deploy a .dacpac from a referenced NuGet package. It works by including some MSBuild magic to create classes that inherit from the new IPackageMetadata interface. This interface exposes the Package ID, Version and the physical path to the package in the users NuGet package cache.

We then leverage this metadata at runtime to find the correct path to the .dacpac and use the existing infrastructure for deploying said .dacpac to a target SQL Server.

PR Checklist

• Created a feature/dev branch in your fork (vs. submitting directly from a commit on main)
• Based off latest main branch of toolkit
• PR doesn't include merge commits (always rebase on top of our main, if needed)
• [] New integration
  • Docs are written
  • Added description of major feature to project description for NuGet package (4000 total character limit, so don't push entire description over that)
• Tests for the changes have been added (for bug fixes / features) (if applicable)
• Contains NO breaking changes
• Every new API (including internal ones) has full XML docs
• Code follows all style conventions

Other information

[jmezach]

@aaronpowell @ErikEJ I think this is ready for review now :).

[ErikEJ]

LGTM!

[aaronpowell]

Only the slightest nitpick in formatting

[jmezach]

@aaronpowell Do we publish NuGet packages from these PR's? I wanted to make sure that the NuGet package actually contains the MSBuild logic so this will work end-to-end in a real project ;)

[jmezach]

@aaronpowell Never mind, I've downloaded the NuGet packages from the CI pipeline artifacts and added those to a sample project and it all seems to work as expected. So I guess we're good to go here :).

[jmezach]

Now that I've tried this out on my own I'm wondering if we should make a change. Specifically related to the resource being returned by AddSqlPackage. This currently returns a SqlProjectResource which I guess can be confusing for some. But more importantly it is not easy to distinguish in code between different SqlPackageResources (if we call it that). That kind of makes it hard to further customize those resources.

For example, one of the scenarios I'm thinking of using this for is for our "ConfigurationDatabase". This is a central databased used by many of our services which contains a registry of tenants and their associated database(s). So, what I would like to provide is something like this:

var builder = DistributedApplication.CreateBuilder(args);

var sqlServer = builder.AddSqlServer("sql");
var configurationDatabase = sqlServer.AddDatabase("ConfigurationDatabase");
var tenantDatabase1 = sqlServer.AddDatabase("Tenant1");
var tenantDatabase2 = sqlServer.AddDatabase("Tenant2");

builder.AddSqlPackage<Packages.ConfigurationDatabase>("ConfigurationDatabase-Schema")
       .WithReference(configurationDatabase)
       .WithTenantDatabase("Tenant1", tenantDatabase1)
       .WithTenantDatabase("Tenant2", tenantDatabase2)

builder.Build().Run();

Obviously this would require implementing a WithTenantDatabase extensions method. But currently I'd add have to make that an extension method on IResourceBuilder<SqlProjectResource>, meaning you could call this on any database. But that won't work, since the extension method will make assumptions about the underlying schema of the database.

So perhaps we should have AddSqlPackage<TPackageMetadata> return a IResourceBuilder<SqlPackageResource<TPackageMetadata>> instead of a IResourceBuilder<SqlProjectResource>?

[aaronpowell]

@aaronpowell Do we publish NuGet packages from these PR's? I wanted to make sure that the NuGet package actually contains the MSBuild logic so this will work end-to-end in a real project ;)

I see you found it, but also, they are published to the Azure Pipeline feed on PR (main will land on NuGet).

[aaronpowell]

If there's the potential that you'd want to do different things depending on whether it's a Project or Package based setup, then I'd suggest that we want to return a different type.

But if it's possible that there would be methods that would make sense whether it's a Project or Package, should there be an interface that both SqlPackageResource and SqlProjectResource could implement (even if it's just an empty interface) so a method could have a constraint of where TResource : ISqlDeployResource (or whatever it gets called).

[jmezach]

Technically I don't think there is a reason to differentiate between packages and projects. In the end both are based on a .dacpac, it is just a matter of where that .dacpac is being sourced from. So I guess it should have been a DacpacResource but that would require doing a breaking change at this point. Perhaps we could do this in a non-breaking way by adding an IDacpacResource interface that both SqlProjectResource and SqlPackageResource would implement?

My main point though was about being able to differentiate between multiple SqlPackageResources in code. If you're sourcing multiple different NuGet packages with different schemas I think you'd want to be able to target the different resources in your project.