Feature Request: Contributors, add parameter to allow load path to be passed in

[GoEddie]

When we load deployment contributors, the path they are loaded from is pretty esoteric (a subfolder of the sqlpackage.exe that is currently executing or a known path in "c:\program files (x86)") this makes deploying contributors almost impossible without admin rights.

Please give us a parameter we can use like /p:DeploymentContributorLoadPath=c:\blah;c:\blah\blah wich will be search locations for deployment contributors.

thanks!

[pensivebrian]

This is on my list to fix and release in the next couple of months.

[GoEddie]

Excellent thank you :)

[pensivebrian]

@GoEddie - I'm implementing this now, and I wanted to run some approaches by you and get your thoughts.

My current thinking:

1. Load any contributor assemblies from the same directory as the dacpac. In a sqlproj, a customer would add a reference (project or file) to the contributor assembly. This way, the contributor assembly is output by the build along side the .dacpac and loaded without having to deal with any paths. I think this guides users to think of contributor assemblies as a build artifacts to include with a .dacpac.

2. Load from an "Extensions" directory relative to the sqlpackage binary. Placing contributors here would handle the use case for reusing common contributors across all multiple deployments.

3. Adding another a command line parameter to sqlpackage /p:AdditionalContributorPaths=C:\Temp and the corresponding DacService DacDeployOption.AdditionalContributorPaths API, is an option. But I think the # 1 and # 2 conventions cover the bases, and I'm wonder if we need this. I'm leaning towards not adding this.

What do you think? Would # 1 and # 2 meet your needs, or do we need # 3?

[GoEddie]

Hi Brian,

I think for option microsoft/DACExtensions#2 it would be impossible to version contributors and you would need a different sqlpackage for each different contributor version?

If you went with microsoft/DacFx#393 and you referenced dacpacs in different directories using the hintpath, would all the directories be searched?

For me, number microsoft/DACExtensions#3 is the best way - we could then include contributors in nuget packages which end up being something like package/lib/net40/contributor and we can share the same contributor version with other builds. Each build can specify exactly the contributors and versions that we want loaded.

ed

[pensivebrian]

I think for option 2 it would be impossible to version contributors and you would need a different sqlpackage for each different contributor version?

Each sqlpackage version has it's own Extentions sub-directory, so yes contributors, will been to be compiled against that version.

If you went with 1 and you referenced dacpacs in different directories using the hintpath, would all the directories be searched?

No, just the directory of the target dacpac being deployed.

Thanks for the feedback. I'm moving forward with all three. However, I'm not adding sqlproj support for specifying addition paths. This will be a deployment time only construct via sqlpackage or the DacServices API.

[GoEddie]

Awesome! This sounds amazing :)

[JanMulkens]

+1 for this Not sure what the end product will be, but being able to include a contributor in a sqlproj and have that as output with the dacpac and being able to deploy it, all in 1 smooth flow without even requiring admin rights would be a much much much better experience than the semi-nightmarish scenario i'm/we're in right now.

[pensivebrian]

The sqlpackage 18.3.1 release has this update. Please open an issue in this project if you run into any problems.