Octopack - should be able to be added to Database Projects

[dazinator]

I hate database projects - DbUp is my preference.

But unfortunately, I have to work with them - because I haven't yet got around to convincing everyone in my team that DbUp is better :)

At the moment, I can manually add the targets to the .sqlproj file like this:

<Import Project="..\..\..\packages\OctoPack.3.0.31\tools\OctoPack.targets" Condition="Exists('..\..\..\packages\OctoPack.3.0.31\tools\OctoPack.targets')" />
<Target Name="EnsureOctoPackImported" BeforeTargets="BeforeBuild" Condition="'$(OctoPackImported)' == ''">
  <Error Condition="!Exists('..\..\..\packages\OctoPack.3.0.31\tools\OctoPack.targets') And ('$(RunOctoPack)' != '' And $(RunOctoPack))" Text="You are trying to build with OctoPack, but the NuGet targets file that OctoPack depends on is not available on this computer. This is probably because the OctoPack package has not been committed to source control, or NuGet Package Restore is not enabled. Please enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=317567." HelpKeyword="BCLBUILD2001" />
  <Error Condition="Exists('..\..\..\packages\OctoPack.3.0.31\tools\OctoPack.targets') And ('$(RunOctoPack)' != '' And $(RunOctoPack))" Text="OctoPack cannot be run because NuGet packages were restored prior to the build running, and the targets file was unavailable when the build started. Please build the project again to include these packages in the build. You may also need to make sure that your build server does not delete packages prior to each build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317568." HelpKeyword="BCLBUILD2002" />
</Target>

OctoPack then runs and packages things up nicely.

The problem is, when I update OctoPack through NuGet, I have to remember to manually update these targets in the .sqlproj files.

Can't Octopack just support this project type?

If it did, I'd gladly contribute a step template to the library for deploying the subsequent DacPac that these NuGet packages end up containing..

[DamianMac]

Hi @dazinator

We're pondering better dacpac support at the moment, for the time being though maybe this will help http://swoogan.blogspot.com.au/2015/04/deploying-dacpacs-with-octopus-deploy.html

[vanessalove]

@dazinator Octopack is opensource and we accept PRs :) Closing this out as it is not on our current planned changes.

[dazinator]

• If I send a PR for Octopack to add support for database projects, will you send me a mug / some pens? :)

[CoreyBovalina]

I believe the issue lies in the fact you can't add Nuget packages period to database projects inside of visual studio.

[dazinator]

@bova80 - You are right - i've just discovered this. Any creative ideas for a work around?

I'm thinking.. a solution level nuget package, explicitly for database projects something like OctoPack.Database - that when installed into the solution, will run an install.ps1 that finds .sqlproj files, and includes the targets.

Obviously this isn't the best, but I can't think of any nicer workaround / solution. Can you?

[dazinator]

• looks like nuget won't be addressing this issue anytime soon either: Support for SQL Server Database Tools projects NuGet/Home#545

[CoreyBovalina]

What you could do is just have a generic folder where octopack lives and reference that and then when it comes time to update you just drop the new version in and don't have to use a version number. So where you have the import project just get rid of the version number in the folder name altogether and have a static folder for it. Hope that makes sense.

[dazinator]

Yep that makes sense, and I can easily do that and then my situation will be sorted. But i'm trying to think of a solution that is entirely automated, thus making it super trivial / less hassle for anyone else who also wnats to use octopack with database projects.

I think a solution level NuGet package would work in the way you described, i.e it would live in one place, and be referenced centrally from individual database projects, however it would have the following benefits over manually creating this setup:

1. Upgrading / Installing is handled via standard NuGet package management functionality
2. No manually copying / moving / renaming of files (i.e to remove a version number from the file names)
3. No need to initially manually edit any sqlproj files (i.e to add the targets pointing a non version numbered octopack targets file)

If I get some time, I'll continue down this route with a PR

[dazinator]

PR Submitted.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.