Idea: alternative for master.dacpac NuGet

[BenjaminAbt]

Currently, the dacpac file of the master table must be in a NuGet package, where the name of the dacpac must also match the NuGet package. This is a bit cumbersome and requires e.g. either publishing to a public NuGet or the NuGet must be stored separately e.g. in a defined local folder (via NuGet.config).

It would be more practical if you could simply put the dacpac file raw into the project, e.g. in a "schema" folder.

Of course, the friendliest would be an implicit recognition of the dacpac. For the first shot, however, the whole thing could also be made explicit.

    <ContentType
        Name="schema/master.dacpac"
        ItemType="SchemaDependency">
    </ContentType>

This idea comes from a recent project where I have moved dozens of applications to this library and the NuGet is a small but still present hurdle.

[jeffrosenberg]

I have mixed feelings on this. I can acknowledge that it would remove some barriers, but on the other hand, I'm not sure whether those are barriers we actually want removed. In general, package management in the dotnet space should be done by NuGet, and I don't know whether we want to re-invent that wheel. Ultimately, I'm ambivalent, curious what @jmezach and @ErikEJ think.

[BenjaminAbt]

I agree with you that the proposal is far from the perfect solution.

The perfect solution would be not to need an external package for master schemas, but for example this would be part of the project or a general NuGet would be available public.

But because of the licensing issue (https://github.com/microsoft/azuredatastudio/issues/14825) this will most likely not happen, so this would be a pragmatic solution.

[jmezach]

This basically boils down to having the ability to <Reference> a .dacpac from an arbitrary location on disk, much like how you can reference a .dll in C# projects. I'm not necessarily against it, but it needs to be very clear that in CI/CD scenario's you're on you're own to get the .dacpac in the right location. You'd either have to make it part of your repository, which is a bad practice IMHO, or download it from somewhere in your CI/CD pipeline.

[BenjaminAbt]

Just so I understand it better myself: why is it a bad practice?

From my perspective, it is currently that I have to unnecessarily setup a package management that was not necessary before. And the package management is also a workaround (via a NuGet as part of the repository in a "package" subfolder), since I don't have a private NuGet server and can't use public.

But my perspective here is certainly not general.

[jmezach]

Checking in binary files into Git is a bad practice since Git isn't very good at storing binary files. I guess you could use Git LFS to alleviate the pain, but that does add an additional thing to think about. That's probably why most platforms have some kind of NuGet feed built-in these days, like GitHub and Azure DevOps do.

But as I said i'm not entirely against it, it is just a matter of it not being a priority for us since we wouldn't be using it ourselves. So if somebody is willing to put together a PR for this I'll gladly review it.

[jeffrosenberg]

The whole conversation is really frustrating to me, since NuGet is clearly the correct solution here, but there's no public NuGet artifact available for the Microsoft master.dacpac file. That's despite the fact the master.dacpac is distributed with every installation of SQL Server, and that it's even available in open-source repos such as Azure Data Studio.

[BenjaminAbt]

The whole conversation is really frustrating to me, since NuGet is clearly the correct solution here [..] and that it's even available in open-source repos such as Azure Data Studio.

I totally agree :-/

Checking in binary files into Git is a bad practice since Git isn't very good at storing binary files.

In principle, I fully agree with you when we talk about binaries in general. However, here it is a 70 KB binary file :-) so... the sledge-hammer to crack a nut? :-)

[ErikEJ]

master.dacpac is coming soon.