Saga sql scripts not generated with dotnet core transitive package dependencies

Hi,

We have a set of services that we are migrating to dotnet core and NServiceBus7 at the moment. We have a wrapper project that facilitates configuration of endpoints which references NServiceBus.Persistence.Sql (4.5.1). From the actual service endpoints in dotnet core (targeting netcoreapp2.2), we reference our own wrapper assembly, which brings in NServiceBus.Persistence.Sql via transitive nuget dependency.

All work fine so far, apart from the saga create/drop scripts that are supposed to be generated during build process inside bin/…/NServiceBus.Persistence.Sql/Sagas folder. The Outbox/Subscription/Timeout create/drop scripts are generated successfully though.

As a solution, if we reference the NServiceBus.Persistence.Sql package directly from the endpoint project, saga scripts are generated fine during build.

I have gone over the relevant documentation several times so far, and not sure if this is addressed anywhere. Is there a endpoint configuration that I am missing somewhere?

The issue happens with both Saga and SqlSaga derived sagas.

Thanks in advance.

You’ll need to reference the NServiceBus.Persistence.Sql package directly in the projects that contain the sagas. A transitive reference to the package will not work.

This is a limitation of how NuGet works. There is a new feature added in NuGet 5.0 that we could leverage to make transitive references work also, but even if we did that, it’s not supported in VS 2017, so you’d have to be using VS 2019 to take advantage of it.

1 Like

Thanks for the answer. Regarding nuget limitation, how about using Paket as an alternative? Would that help at all?

No, using Paket would not make a difference because all it does is alter how you acquire the packages. Behind the scenes, it’s still creating a PackageReference for each package to add them to your SDK-style project.

More importantly, you’d also still be using a ProjectReference in your project file to add a reference between projects, and the behavior of what flows transitively across those is unaltered by using Paket.

The contents of the build folder inside a NuGet package does not flow transitively across a ProjectReference, and that’s the design limitation I was talking about before.

NuGet 5.0, which is included in the latest .NET Core SDKs and VS 2019, now supports a buildTransitive folder as well, and the contents of that will flow transitively across a ProjectReference.

However, given that it only works with the latest version of NuGet, it’s not yet clear when it makes sense for us to consider adding support for it.

1 Like

Sorry for necroing the post, but perhaps this would be useful to mention in the documentation? It was not exactly obvious to me, and required some Googling to get working.

@Rasmus_Hansen I added a warning box about that here:

Does that help?

Yes, that would clear it up. Thank you!