Streamlining Dependency Management in Visual Studio

I’ll start out with a disclaimer: What I’m going to talk about in this post represents some thoughts that are being batted around by a few of us. It does not represent any decided on features for any future version of Visual Studio.

Now, with that out of the way, one aspect of Visual Studio that drives me absolutely crazy is the number of different experiences avaiable for adding dependecies into my project. Let’s take a quick inventory based on Visual Studio 2013:

  • Add Reference – for assemblies, project references, COM references and SDKs
  • Manage NuGet packages – for…well…NuGet packages
  • Add Service reference – for SOAP-based services
  • Add Connected Service – for Azure Mobile Services integration

In addition to this list, there are also plenty of ‘pseudo-dependency experiences’ – things that may be more specific than say, ‘add reference’ but have the same basic characteristics. A good example of this in Visual Studio 2013 would be the Add->Push Notification feature. Also, there are plenty of 3rd party and future experiences that aren’t on this list and would add yet another menu option and user experience.

Stepping back and looking at all of these different component types and related experiences, they all need to do the same basic operations (note that I said need here – some of the current experiences have a weak or no story for some of these):

  • Enable discovery of components
  • Enable installation of components
  • Enable update of components
  • Enable removal of components

The differences lie not in what the experiences need to be, but rather in how they need to work for different component types. For example, consider the installation experience. There exists a common semantic across all types of dependencies – “I want to add stuff to my solution to help me focus on writing code that adds value to my application.” While this forms the big idea for what adding a dependency should mean, it can manifest in very different ways based on the type of ‘stuff’ you’re adding. For example, adding a NuGet package dependency may add assembly references and drop some content files in your project, while adding Azure Mobile Services dependency may provision a service in the cloud, add some assembly references and scaffold out some code to enable your code to more easily communicate with the service. Unsurprisingly, these same kinds of differences crop up when looking at update and removal as well.

In terms of managing dependencies, one comment I’ve heard from more than a few people goes something like this: “Well, NuGet has emerged the clear winner in the dependency management space – so why not just NuGet all the things?” Two responses there:

  1. Is NuGet really the clear winner in all contexts? I’m seeing a lot of folks starting to use NPM for other-than-node applications and I’m seeing a lot more chatter and use of Bower for client-side dependencies in Web applications. Don’t get me wrong – I’m a big fan of NuGet. However, I think it’s dangerous to craft a strategy around the idea that a particular technology is and will forever (or at least for a really long time) be *the* technology. Besides, we’re all a little hipster when it comes to technology – once a tech becomes the established thing (dare I say, the ‘enterprise’ thing?), it’s no longer as exciting as the next up and coming thing :)
  2. By trying to make NuGet into the “one ring to rule them all”, we would end up destroying NuGet. Yes, I said destroy. I’ve been around for a while now, and nothing seems to kill a promising technology faster than initial success followed by a morphing of the technology to address scenarios that go far beyond its initial vision and goals. For NuGet to continue to evolve in a way that is useful, I believe that it needs to manage the scope of what it should do, and then focus on doing those things really, really well.

The solution is not to make one package manager the “one”, but rather to make it insanely easy (transparent-even) to use multiple package managers in Visual Studio in a single depenedency management experience.

Oh, and did I mention that we should reduce the number of menus in the solution explorer context menu??

So at a high level, here’s what we’re thinking about:

  • Create a single point of entry/UX for managing dependencies in a Visual Studio project or solution – both Microsoft and 3rd party (e.g. NuGet, assemblies, NPM, Bower, etc…)
  • Dependency discovery is “search-first” by way of a common service for indexing and making contextual recommendations. This would be a pretty profound change from the traditional Microsoft developer tools world of enumerating lists and trees.
  • Different types of references can have their own user workflows. Not sure the best way to design this (you’ll be relieved to know that we immediately ruled out the “10 layers of modal dialog” option :))
  • Dependency types are identified by name and/or iconography – but not physically separated by tabs, etc. The point is that search goes across providers and may show, for example, a Bower package and a NuGet package in the same list of results.
  • All dependencies are first class in Visual Studio. Practically, this means that are all managed (e.g. update/remove) the same way in Visual Studio components such as Solution Explorer.

If we moved forward with this, it would be a pretty significant change to some pretty core Visual Studio experiences. So I want to get your thoughts. Here are a couple initial questions:

  • Do you currently use multiple dependency management tools experiences when building apps – and if so, for what types of apps?
  • Do you currently end up leaving Visual Studio completely for certain types of dependencies – and if so, for what types of dependencies and for what types of apps?
  • If you’re currently switching between different experiences for dependency management, is this something that’s a point of frustration (or possibly a frustration that you’ve just gotten used to)?
  • Is a consolidated dependency management experience something that you would find helpful/valuable?
  • Moving to a search-first experience feels like a pretty big shift – is it realistic to attempt this or do you feel like you need to be able to browse/enumerate?

I’m sure I’ll have tons more questions as we continue to explore this space, but want to kick off the conversation and get your initial reactions/thoughts.

Update (2013-10-8): came across the following article which describes a solution to the same kind of problem that this approach would address:

About Howard Dierking

I like technology...a lot...
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Paul Turner

    For myself, discovery of packages happens entirely outside of Visual Studio. I find them through blog posts and searching for packages which can solve specific problems. In both cases, researching what a package can do and how I might use it to solve an immediate problem before going into Visual Studio and (usually using NuGet) adding the reference I want.

    NuGet succeeds for me because it provides a single searchable registry from which it’s frictionless to add the reference I’m looking for. I get the same flow adding reference assemblies and projects. I’m not sure I’d find it easier to integrate these things into a singular search. Normally I know what kind of thing I’m adding before I start adding it, because there are steps to being “ready” to add it, like adding the project to the solution or installing an SDK. Worse, if I have the option to install a package from NuGet or from reference assemblies (like in the case of something like the Azure SDK), having both options show up in a search forces me take extra care in choosing the right thing.

    Actually, I think I would prefer a singular UX for two distinct operations: Add and Manage.

    For Add, give me the option to switch between the types of reference – I can make that distinction very easily, I know what I’m looking for. Some of them will be a search over a registry (like NuGet and reference assemblies), others will more targeted (like adding a URL to a service, or to an stand-alone assembly).

    For Manage, list all the things I currently have installed and let me perform context-specific operations on them, such as “Update to Version” in the case of a NuGet package, or “Refresh” in the case of a Service Reference, and to remove them entirely. This would make it easy for me to consolidate what my project is dependent on and then perform the general management of them.

  • howarddierking

    On enumeration being best for discovery, do you find this to be true for all types of references – specifically, NuGet packages? I have to say that I’m a little surprised by this, since I can’t imagine ever having the patience to browse through 10,000 packages. Same (for me) with npm – same for homebrew – same for bower…

    What am I missing?

  • Pär Björklund

    My two cents. Search is best when I know what I want and want it quickly(keyboard friendly)
    enumeration is best for discovery, when just browsing throughout the repo to find something interesting I can use

  • devtools.korzh

    Great thing. It was really worth my time.

  • Joeyw

    Great post, but I think there’s a wider problem here.

    I would prefer we separate out the GUI problem and the technology underneath. I would imagine the use of bower, npm and
    other tools will increase over time. There’s an open question of how Nuget will integrate with these other languages. For example, should Nuget delegate to bower for client side JavaScript dependencies? What about other build systems like grunt? Should MSBuild (and Visual Studio) work these build systems? If these issues are solved, then the GUI should be simple. If the GUI is hiding a mess of incompatible build and dependency management systems underneath then I
    see this as less than ideal. It’ll solve the “Add Dependency” problem, but what about build, deploy and test? What about adding a dependency onto a package that is built using a different build system?

  • Mark Seemann

    Howard, I think this sounds promising.

    Currently, I almost exclusively use NuGet from the built-in Visual Studio Package Manager Console, and feel quite alienated when, once in a blue moon, I actually have to add a BCL reference to a project. Actually, I don’t think ‘struggle’ is an exaggerated choice of word when it comes to describe my experience with the built-in Add Reference dialogue.

    Whatever you do in this space, however, please keep the following in mind:

    – Make it possible to use a command line, just as is currently possible with the Visual Studio Package Manager Console.

    – Make it automatable (should come automatically if you grant my first wish).
    – Make it Version Control System (VCS)-friendly.
    – Make it Build Server-friendly. This may require a bit of explanation, but actually touches on things such as network access rights and so on. As an example, the NuGet package restore feature is actually quite Build Server-unfriendly, because if, for some reason, the Build Server can’t access the network (of if is down) the build fails. Thus, checking dependencies (binaries, etc.) into VSC should always be an option. This would enable a Build Server to just pull down the code and compile it.

  • Tudor

    As other have said, I wouldn’t find useful such an “universal” Swiss-army tool..
    Even with NuGet, many .NET programmers are still not used to it, and prefer to manage the dependencies manually.

  • Colum Clissmann


    First off, good idea on opening the dialogue, if you’ll excuse the pun.

    I’ve worked with many dependency management points in Visual Studio and find nuget far and away the winner. That said I’d be loathe that experience having to accommodate a load of edge cases around things like soap, etc. I’d prefer to see them left to the side.

    On search, I think it could be great but would image it might be best as a first class alternative to browsing. Possibly defaulting based on a user option. Do not underestimate how entrenched many users are in the way the work and they will rightly say why has there cheese been moved. Think the change to pending changes and how that went down; btw, I was all for the change. So why move and not just offer an alternative?

    If the consolidation into ~nuget is painless I’d be for it otherwise I’d second what @ThomasWeller:disqus wrote.


  • Thomas Weller

    Hi Howard,

    just my five cents:

    While thinking about how our work could be made easier is always worthwhile, I wouldn’t like this consolidation very much, to tell the truth.

    From my point of view, this would be something that is desirable for end-users/consumers, who don’t like to read, but make things happen – without caring too much about the details. But programming is not an end-user thing, and as a software developer, I need all these – sometimes nasty – details to get my job right.

    IMHO, a uniform treatment of technically totally different things would hide much of these details and would give a false sense of simplicity that is not appropriate here, since a programmer has to deal with quite complex technical issues here. – This is not to say that all these kinds of dependency management don’t have much room for improvement in terms of UX – some of them even VERY much room ;-). I just don’t want to see them all lumped together – in the end, it would make the job of developing software harder, not easier (my experience is, that you ALWAYS have to dive down deep into the details anyway for some reason or the other…).

    – Thomas