Idea: allow a `csproj` file to recommend (but not depend on) `vsix` extensions

Visual Studio Version: 16.0.0 Preview 4.0

Summary: As a developer who’s new to a project, it would be a nice onboarding measure if the IDE could recommend useful vsix extensions (and possibly NuGet packages, etc.) that aren’t strictly speaking required. VS already does this to an extent, but it doesn’t currently appear possible for the author/team that maintains a particular project or solution to customize this behavior.

For extensions the lack of which actually would impede the developer workflow, an additional Severity could be introduced, corresponding to the Error List.

When lacking an extension, an information bar is shown to offer installing the extension. Given a high severity, a modal dialog might be preferable.

Proposed syntax:

<ItemGroup>
  <SuggestedExtension ID="51b81721-cf4e-4ce0-a595-972b1ca2a186" Title="SCSS Refactoring" Severity="Info" />
</ItemGroup>

Examples:

• an ASP.NET project could suggest extensions such as Web Compiler, SCSS Refactoring, etc., with Severity Info
• a C# library that heavily follows a certain coding standard could suggest an extension that enforces it, with Severity Warning
• a mandatory part of the toolchain, such as version control or a post-build step, possibly with Severity Error

User Impact:

The impact is comparable to a How to Build section in a good readme: it helps with onboarding, but requires maintainer discipline. Unlike such a section, it adds a level of automation to the process.

[davkean]

@chucker VS picks up the .vsconfig if its included in the solution as an item, and checks against installed features. Checking against installed extensions would be a nature extension of that.

[davidwengier]

I’ve worked on projects in the past where this would be a great idea. Specifically in that case it was the Razor Generator extension, and it was compounded by their being a few extensions with that name and having to know which was the right one to pick. If it was feasible I’d even support an <ExtensionReference> concept that just installs the extension directly.

The question is whether these extensions would actually be better off being re-written as nuget packages that contain roslyn analyzers (for your 2nd example) or targets files (for your 3rd example).