SQL Project / .dacpac support

[ErikEJ]

See dotnet/aspire#1696

I am contributor to a repo, where @jmezach is working on support for deployment of a .dacpac to a SQL database, the .dacpac can originate from our project SDK and we also support .sqlprojx - .sqlproj using the CSP project style with the Microsoft.Build.SQL SDK

@aaronpowell Would this be something that is relevant in this repo, and what would we gain from publishing it here?

[aaronpowell]

From the overall perspective of provisioning a database schema - I think this is an important problem to solve and the thread you linked to shows something that looks like it would fit into the Aspire overall workflow/design, so I'd support the creation of that extension.

Would this be something that is relevant in this repo, and what would we gain from publishing it here?

Let me answer these questions by answering them in the reverse order:

what would we gain from publishing it here?

This is something that we probably need to do a better job of articulating in our README/FAQ docs because it's a valid question why should I contribute here rather than my own repo/package. When I proposed the idea of this project my goal was to have a place for the Aspire community to centralised "hub" for extensions for Aspire (hosting integrations, client integrations, extensions on integrations). By having a centralised project, we can improve the discoverability - you don't have to type "aspire+" into a search box on nuget.org or a search engine to see if something already exists.

So, we've tried to make this approachable for anyone who wants to contribute through the patterns in place, the testing framework, and the release model. With this in place someone can contribute an integration and then (if required) we can help refine it to fit our model, and they can choose to join the team and continue to maintain it or hand it over to be maintained by us if they aren't in a position to (although we may not be experts in that particular area so we do encourage people who want to contribute to continue on).

But if people already have a project/repo around something they want to integrate into Aspire we do encourage them to built it in their own repo as well if they'd prefer, we're not here to "own" the Aspire extensibility space, just to give people a choice around it.

And this brings us to the other part of your questions:

Would this be something that is relevant in this repo

As I mentioned at the top, this is a problem space I've heard about many times with Aspire, as provisioning/seeding a database is something that you need to do so I'd welcome this as a contribution as it's probably not something that we have the skills in the team to build ourselves.

[jmezach]

Perhaps it makes sense to contribute what we have here. It isn't necessarily tied to MSBuild.Sdk.SqlProj anyway, since it already works with the new .sqlprojx format as well. And we can probably support the old .sqlproj format by doing some assumptions.

[ErikEJ]

@aaronpowell @Alirexaa I would like to know what you think of the API shape here (I you have time to have a look) - I wonder if it is in line with the standard Aspire API shape?

https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/blob/1983e243023bff53178e0636fc5afd5ee06e1afd/test/TestAspireHost/Program.cs

Should .PublishTo be .WithReference ??

Should .FromDacpac be .WithDacpac ??

/cc @jmezach

[aaronpowell]

It should be WithReference since it's a reference to the SQL database that is being forwarded to the consuming client, and WithDacpac, as you're adding that as an extension (under the hood I'd assume it uses an annotation) to the resource.

[aaronpowell]

Closing as we have now released this as an integration