Can octopack be used to create consumable nuget packages?

I’m trying to set up our build process so our CI server, TeamCity, generates Nuget packages which can be used by other projects but also sends or makes these packages available to Octupus for deployment. Everything works great for the deployment part but it appears that the packages created by Octopack aren’t valid for consumption as a standard Nuget package.

Hi Matt,

Thanks for reaching out. Octopack uses Nuget.exe in the background, so they should absolutely consumable as standar Nuget packages. You could even push them to, , etc and the should work.

I understand that you tried to consume the packages in some way from another tool other than Octopus, and it didn’t work. Could you give me more details about this and how you tried to consume them (which didn’t work)?


Hey Dalmiro,

Thank you for the response. I’ve been attempting to add the Nuget packages to another .Net project. When I add the package I get the following error:







Suppression State


Could not install package ‘{package name}’. You are trying to install this package into a project that targets ‘.NETFramework,Version=v4.5’, but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.


On the surface it seems like a pretty straightforward error, however I’ve tried using pretty much ever Framework version I could think of on the target project and still get the same error (just with a change in .NETFramework version). Looking into the package it doesn’t appear to have the standard lib/version structure but instead has just a straight up bin directory.

Hi Matt,

Sorry for the delay here. When you say " I’ve been attempting to add the Nuget packages to another .Net project.", which package are you trying to add to another project?

A) Octopack
B) Another package that you created from another project using Octopack. If this is the case, on which .NET version was this project built on?



Sorry for not being clear. Here’s the full scenario:

Project 1 is built and a Nuget package of Project 1 is created using Octopack.
Project 2 attempts to consume the Octopack generated Nuget package of Project 1.

Both Project 1 are Project 2 are on the same version of .Net, 4.5.

Hi Matt,

I’m helping Dalmiro with your question. I tried to reproduce the error and I was surprised you were correct. I would have assumed the NuGet packages produced would be perfectly fine to be consumed by other apps/solutions but it wasn’t the case. I created a test library, packaged it with OctoPack and it’s contents were a flat list of the library bin directory’s contents (i.e. a single DLL and it’s associated PDB file). I re-read our OctoPack documentation page ( it reminded me that it’s purpose is to simply be the easiest way to package an app or service. It’s purpose is not to create re-usable NuGet packages.

If you’d like to have OctoPack build a package that can be reused, you can always add a nuspec file to control the structure of the package. More info on that at is available on the the OctoPack documentation page and the official NuGet documentation site ( That said, it’s important to keep in mind that this structure will also be unpacked on target machines. For example, you may need to specify a relative home directory if you’re deploying a IIS web site.

Hope this helps.



We have the exact same scenario, using CI to build and create “nuget consumable” class libraries that can be used ar normal Nuget references in other projects.

Looking at other (valid) “class library nuget packages”, I was able to figure out thatt my dll’s should go into /lib/net451. This can easily be accomplished using in a NuSpec-file that OctoPack will automatically pick up. Eg:

It would be useful if OctoPack supported this by default, since I dont really want to hard-code the framework-version in my NuSpec-file. Tip: use nuget package explorer to create packages, this program has ready made options for adding special folders such as the lib/net451 etc.

Hi Emil,

Thanks for reaching out. For the time being we’ll stick with the workaround propossed by Rob above. If you’d like to have a different way to package libraries so they can be consumed, would you mind submitting it as a uservoice suggestion?