1

We are going to publish one of our commercial components, a .NET grid control, as a NuGet package. The product is separated into 2 DLLs - one is the core functionality, and the other is the design-time support assembly. The core assembly can be redistributed as a "normal" DLL and can be placed into any location. But to make the whole product work properly in VS IDE, the design-time part should be installed into a special folder like the Visual Studio PrivateAssemblies folder or into any folder with a special registry key that points to it. Do NuGet packages allow us to do this?

TecMan
  • 2,743
  • 2
  • 30
  • 64
  • No, to tinker with the private parts of VS you should be considering a [VSIX package](http://msdn.microsoft.com/en-us/library/ff363239.aspx). – Hans Passant Feb 17 '14 at 14:37
  • @HansPassant, What about to use a PowerShell script for that? It can be a part of a NuGet package, and it can execute automatically when the package is installed. – TecMan Mar 12 '14 at 14:46

1 Answers1

0

You need to use Chocolatey packages for a run-time dependency like this. NuGet packages are [designed for] for build-time dependencies only. See http://chocolatey.org/ - Chocolatey uses NuGet under the hood, but has a different focus. You'd probably use NuGet for the "anywhere" DLLs, and a separate Chocolatey package for the VS designer support.

Matthew Skelton
  • 2,220
  • 21
  • 21
  • The question was about the NuGet package manager itself. We cannot force VS users to install other tools, we can use only the standard set of features available in the latest versions of VS. – TecMan Feb 19 '14 at 06:16
  • 1
    My point is that NuGet is a tool designed for one job: build-time dependencies. If you wish to try to use it for something else, then that's up to you, but you cannot expect tools to work outside their designed parameters. NuGet is for build dependencies, Chocolatey for run-time dependencies. – Matthew Skelton Feb 19 '14 at 16:59