So I understand that this is a shortcoming in the way Nuget works (probably because it wasn’t directly meant to be a service deployment mechanism) but resolving dependencies differently could be useful in the following scenario.
Suppose you have several services and all those services have a dependency on a common set of dlls. If you set up a package for those dlls and include them as a dependency on your service nuspec file then the dependency dlls get deployed in their own directory using nuget install, rather than being included in the same directory as the service dlls/exes. Obviously this means the service won’t run.
Now the benefit of supporting this would be that you don’t have to maintain several nuspec files updating these core dependencies.
How does Octopus Deploy get round this?
Thanks for getting in touch. Octopus doesn’t support NuGet packages with dependencies, usually the workflow is something like:
- Build server builds app, including NuGet dependencies => single NuPkg
- Octopus deploys the NuPkg to a single directory
We’ve had a few discussions in the past about package dependency support, but for manageability, integrating everything and testing it on the build server before repackaging seems like a good reliable process in practice.
Understood. Maybe my situation is one of the edge cases where we have so
many different processes with common dlls that when distributing over high
latency low bandwidth links it makes sense to reduce the number of times
common dlls are copied (I’ve reduced the amount of data copied to 20%!)
For now we’ll have to stick with just nuspec and nuget pack with a custom
nuget install process handling these dependencies. Maybe octopus will
support this in the future.