Streamlining Dependency Management in Visual Studio | Howard Dierking
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:
- 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
- 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: http://www.wired.com/wiredenterprise/2013/10/runnable/