I suggest you ...

Add Extension SDK Tooling

VS Extension SDKs are a great way of packaging up components, specially with company internal components, native DLLs and also closed sourced (read: paid and/or licensed) SDKs.

They also add a great benefit of consumers of the Extension SDK to easily "Add Reference..." within the VS IDE, making it simple to add these package references, no matter the project type.

1.) It's unfortunate that Extension SDKs have to be created by hand and is very error prone and tedious. It would be very helpful to automatically package up Extension SDKs within a GUI in the IDE.

2.) Also, creating these Extension SDKs are only available to the IDE if placed in a certain directories, or a registry setting is made to point to it. There are current installer solutions to this, some very simple, but it would simplify workflow to simply skip this install step all together. It would perfect if one could simply "Add Reference..." and browse to a directory with the SDKManifest.xml to include the package in a project.

PS - We know about nuget. Not what we are looking for. No thank you.

30 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Jeremiah Morrill shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thanks for taking the time to share this suggestion.

Going forward, our plan for VS “15” and beyond is to quickly address limitations that VS today has around enabling a similar scenario using Nuget. We believe that enabling this support would give users the best of both worlds – an easy way to distribute packages/code, and at the same time all of the Visual Studio tools would end up respecting functionality that today is exclusively supported only by Extension SDKs (for example, designer toolbox, version targeting for Windows SDK, etc.). We are maintaining the specification for that part below, and would love to hear more on what additional parts are missing to bridge the gap:

https://github.com/NuGet/Home/wiki/Converting-Extension-SDKs-into-NuGet-Packages

- The Visual Studio Team

7 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Morten Nielsen commented  ·   ·  Flag as inappropriate

    Howard: In any case this is off topic. The suggestion is to improve how to create extension SDKs, not to improve on Nuget.

  • Howard Dierking commented  ·   ·  Flag as inappropriate

    I know that matrix well as I was one of its authors. The items you mentioned (e.g. those that modify VS state rather than the project/solution state) make sense. They just weren't in your original answer to my question of "why not NuGet" (Paid-for-packages, non-intrusive, no need for nuget server (internal or public), simple distribution) - so wanted to ensure that I understood the core capability gaps.

  • Morten Nielsen commented  ·   ·  Flag as inappropriate

    Howard: Also there's this matrix, that clearly shows that there's a lot of things Nuget doesn't do: http://msdn.microsoft.com/en-us/library/jj161096.aspx
    Personally for me the big-ticket items are:
    - Toolbox integration
    - Snippets and templates
    - SDKs can ship multiple configurations. MSBuild consumes the appropriate files for each project configuration.
    - Support for Design time assemblies

  • Jeremiah Morrill commented  ·   ·  Flag as inappropriate

    @Howard,

    Simply put, I want ext sdks to be as simple as adding ref to .NET assemblies, no matter if C++ or JS or .NET.

  • Howard Dierking commented  ·   ·  Flag as inappropriate

    I understand the paid-for-packages comment. I don't understand non-intrusive (NuGet actually seems less intrusive than eSDKs). You can use NuGet without a NuGet server; and as a result, NuGet is generally simpler for component distribution than eSDKs (e.g. drop nuget packages on a file share vs. building and running an MSI). What am I missing?

  • Jeremiah Morrill commented  ·   ·  Flag as inappropriate

    @Howard

    Paid-for-packages, non-intrusive, no need for nuget server (internal or public), simple distribution

Feedback and Knowledge Base