Visual Studio IDE

Welcome to the Visual Studio UserVoice site. Let us know what you would like to see in future versions of the Visual Studio suite of products. This site is for suggestions and ideas. If you need to file a bug, you can visit our Developer Community website to get started.

Please open up the API for CodeLens now that Roslyn is available to the wider public. It would allow to to do some great stuff on the local code. I would not mind a model that only works locally for now, though a server side API would be nice.

At this point, we’d like to dive further into the specific needs your scenarios will have from the API. If you can spend a few minutes to answer the questions on this survey, we’d greatly appreciate it! Your answers will help us plan and prioritize the work required.

I run the very popular ASP.NET MVC Boilerplate project template extension which is currently the most popular project template in the Visual Studio Gallery.

I am asked every few days to add authentication support to the project template. I want to be able to hook into the "Change Authentication" dialogue and give consumers of my template the choice of which authentication provider they want to add.

We’re looking at this, but our primary concern is protecting the notifications area from abuse. Clearly there are legitimate uses for this capability, but we hear loud and clear from other developers that they do not want this feature opened up broadly, for fear that the signal-to-noise ratio is wrong. Further comments on reasonable restrictions are greatly appreciated as we consider this.

Currently you can have a single .vsix file targeting several Visual Studio versions. But all the content is deployed to all Visual Studio versions. The request is to be able to deploy content based on conditions such as the Visual Studio version, edition, dependency installed or not, etc.

An scenario for this goal is the following: suppose that I have a single package MyAssembly.dll which has two different .vsct tables with different icons for VS 2010 (colorful) and 2012/2013 (gray). So I get two embedded resources such as Menus1.ctmenu and Menus2.ctmenu. Imagine that somehow I get two .pkdef files (MyAssembly1.pkdef referencing Menus1.ctmenu and MyAssembly2.pkdef referencing Menus2.ctmenu). Now, in a single manifest, in the <content> section, I want to specify MyAssembly1.pkdef for VS 2010 and MyAssembly2.pkdef for other VS versions.

Currently you can have a single .vsix file targeting several Visual Studio versions. But all the content is deployed to all Visual Studio versions. The request is to be able to deploy content based on conditions such as the Visual Studio version, edition, dependency installed or not, etc.

An scenario for this goal is the following: suppose that I have a single package MyAssembly.dll which has two different .vsct tables with different icons for VS 2010 (colorful) and 2012/2013 (gray). So I get two embedded resources such as Menus1.ctmenu and Menus2.ctmenu. Imagine that somehow I get two .pkdef files (MyAssembly1.pkdef…

Not all extension writers will update their extensions all the way along VS's upgrade path. And they shouldn't have to if they don't have newer things to add.
However, as a conquence, these extensions won't report compatible with newer versions' of VS. So every time there is a new version of VS, there will be fewer extensions, which is not something that should happen.

We hear you. Unfortunately forward compatibility has proven harder than any of us would like.

Some examples of the complexity here, not as a defense but just in the interests of transparency:
– By default, the extension manifest that is part of the template for new projects in Visual Studio 2015 targets just the current version, which is probably too conservative;
– We changed the signing mechanism between Visual Studio 2013 and Visual Studio 2015 from SHA1 to SHA256 to keep pace with security standards, which meant that older versions show as incompatible;
– The gallery doesn’t automatically show extensions as compatible with the latest version unless the developer marks them accordingly (even if they are actually compatible);
– In Visual Studio vNext, we’ll install less by default – so extensions that thought they were compatible with later versions may be wrong (e.g. we no longer include the C# language service or web tooling in the smallest installation).

We’re thinking about how we can improve this going forward – but in the meantime we wanted to note that we’re listening and grateful for your feedback.

Warm wishes, Tim Sneath | Visual Studio Team

We hear you. Unfortunately forward compatibility has proven harder than any of us would like.

Some examples of the complexity here, not as a defense but just in the interests of transparency:
– By default, the extension manifest that is part of the template for new projects in Visual Studio 2015 targets just the current version, which is probably too conservative;
– We changed the signing mechanism between Visual Studio 2013 and Visual Studio 2015 from SHA1 to SHA256 to keep pace with security standards, which meant that older versions show as incompatible;
– The gallery doesn’t automatically show extensions as compatible with the latest version unless the developer marks them accordingly (even if they are actually compatible);
– In Visual Studio vNext, we’ll install less by default – so extensions that thought they were compatible with later versions may be wrong (e.g. we no longer include the C# language…

Sometimes I find myself in situations where I wish I had the option to disable/enable specific extensions for specific solutions mainly for two reasons:

1. The extension is heavy and opening large solutions can take quite some time so you're in the mercy of the vendor to improve the experience, the classic example is using R# with large projects.

2. The extension shouldn't even load because the extension isn't used for example using Visual Assist for C++ as opposed to R#.

The problem is when you disable/enable extensions sometimes you lose the configuration and you need to restore it each time so it's really a hassle to switch between extensions and manually configuring keybinds and/or features.

Now, I can probably ask extension vendor to come up with their own mechanism to disable/enable themselves per solution but it's a bit awkward for an extension to enable itself only to find out that it should be disabled and some vendors don't even want to be in that spot, people requested this feature from JetBrains since R# 5.0 and "nothing" was done about it but besides this point it really feels like it should be a feature of the IDE.

What I'm suggesting is to either add a new "section" to `*.sln` files to track extensions or add a new `.vs\extensions.json` file to track it but I think that in order to _really_ solve the issues Visual Studio would need a new infrastructure to store its configuration per extension so something like this:
```
\SomeProject\.vs\extensions\Visual Studio.settings
\SomeProject\.vs\extensions\ReSharper.settings
\SomeProject\.vs\extensions\Visual Assist.settings
```
With this, when R# is disabled two things should happen:

1. Visual Studio should write the state of the extension to `.vs\extensions.json`.
2. Visual Studio should write its current settings to `\SomeProject\.vs\extensions\ReSharper.settings`.

When R# is enabled two things should happen:

1. Visual Studio should write the state of the extension to `.vs\extensions.json`.
2. Visual Studio should read the settings from `\SomeProject\.vs\extensions\ReSharper.settings` and apply them back to Visual Studio.

When a solution loads Visual Studio needs to check the state of the extension and enable/disable it respectively.

When both R# and Visual Assist are enabled there might be some conflicts so one way to solve this is to show a dialog to the user and ask him/her for the default option he/she wants to set and then write it to `\SomeProject\.vs\extensions\Visual Studio.settings` which will be used whenever a conflict exists.

Installing multiple extensions for productivity tools is pretty common, sharing configuration between teams is also common and there's no reason for us to manage these things manually when the IDE should and can do it automatically.

With this improvement it would be easy to share configuration, enable/disable extensions between machines and different solutions.

Sometimes I find myself in situations where I wish I had the option to disable/enable specific extensions for specific solutions mainly for two reasons:

1. The extension is heavy and opening large solutions can take quite some time so you're in the mercy of the vendor to improve the experience, the classic example is using R# with large projects.

2. The extension shouldn't even load because the extension isn't used for example using Visual Assist for C++ as opposed to R#.

The problem is when you disable/enable extensions sometimes you lose the configuration and you need to restore it each…

There exists an API for creating Interline Adornments within Microsoft.VisualStudio.Text.Internal. Please considering moving this to one of the publicly available extensibility assemblies so customers can easily create adornments that exist between lines (similar to CodeLens adornments)

Step into the embedded software development space. I know .NET Micro Framework but that targets larger MCUs and is interpreted, which is not ideal. Target PIC and AVR MCUs and perhaps others. Have an Express version that help Makers to start easily to develop their IoT projects. This could be positioned as an extension of the IoT 'vision'.

It would require VS to run external Tool chains or build support for the MCU targets. Make sure UnitTests and Source Code Control is available and provide good low level insights in the generated/compiled code.

Popular board can maybe also be supported in the future (Arduino, RaspberryPi, BeagleBone etc).

Step into the embedded software development space. I know .NET Micro Framework but that targets larger MCUs and is interpreted, which is not ideal. Target PIC and AVR MCUs and perhaps others. Have an Express version that help Makers to start easily to develop their IoT projects. This could be positioned as an extension of the IoT 'vision'.

It would require VS to run external Tool chains or build support for the MCU targets. Make sure UnitTests and Source Code Control is available and provide good low level insights in the generated/compiled code.

Now that NuGet is fully integrated into MSBuild, VSIX projects should support the PackageReference feature.

If you add a reference manually or through NuGet (utilizing packages.config), the VSIX project automatically includes the assembly since the reference is marked as Reference inside of the csproj file instead of PackageReference.

With VS 2015 we now have the possibility to automatically install/add both server-side packages (Nuget) and client-side packages (NPM, gulp/grunt, bower) to a solution. This is done by simply adding some configuration files (packages.config, package.json, gulpfile.js, etc) to the solution and putting them under version control.

One thing which is missing, is a similar way to allow to configure the extensions/plugins which are required by a Visual Studio solution.

I propose to add the ability to add an extensions.config file to a solution, which lists the extensions/plugins required by that solution.

Whenever someone starts working with that solution, the required extensions are automatically installed (or the user is at least prompted to install them).

This would provide an easy way to ensure that all team members have the same (required) extensions installed (e.g. WebEssentials, editorconfig, etc. come to mind).

With VS 2015 we now have the possibility to automatically install/add both server-side packages (Nuget) and client-side packages (NPM, gulp/grunt, bower) to a solution. This is done by simply adding some configuration files (packages.config, package.json, gulpfile.js, etc) to the solution and putting them under version control.

One thing which is missing, is a similar way to allow to configure the extensions/plugins which are required by a Visual Studio solution.

I propose to add the ability to add an extensions.config file to a solution, which lists the extensions/plugins required by that solution.

Currently, Visual Studio allows developers to sync settings and IDE layouts in VS on multiple machines. It's a great feature but it's incomplete. Extensions are excluded from being backed up and synchronized across installations. Developers find it very tiring to download every single extension they need AGAIN just because their using VS on a different machine. However, all is not lost if the next version can just add this *tiny* feature.

I've run into a couple extension updates (typescript and ASP.Net Web tools) that have shown up in the notifications area and correspond to the Extensions and Updates manager dialog. When I initiate the update via the button in the dialog, they trigger a download in my browser and a separate installer window.
Updates that are advertised in the update manager should be .vsix installs when ever possible (especially for MSFT components) and should install within VS. Ideally without a restart of VS.
Launching a download in the browser breaks the continuity that used to be present in the Extensions and Updates manager dialog.

I've run into a couple extension updates (typescript and ASP.Net Web tools) that have shown up in the notifications area and correspond to the Extensions and Updates manager dialog. When I initiate the update via the button in the dialog, they trigger a download in my browser and a separate installer window.
Updates that are advertised in the update manager should be .vsix installs when ever possible (especially for MSFT components) and should install within VS. Ideally without a restart of VS.
Launching a download in the browser breaks the continuity that used to be present in the Extensions and…

We’re making good progress here, and expect to have solved this problem for the vast majority of Microsoft extensions by the RTM of Visual Studio “15” (the next version of Visual Studio). Extensions that do this are largely MSI or EXE installers which need to perform operations that VSIXv2 doesn’t support. We’ve added more capabilities to the VSIX format for the next release of Visual Studio and the two you mention in particular will be able to install directly using the VSIX installer.

It's very nice that the extension dialog now batches installation.
However, it's still very annoying to be forced to wait while it downloads the VSIX.
Can you make it download in the background (and show a progress bar in the corner status area)?
It'd be fine to block closing the extensions dialog until all downloads finish, but I want to continue browsing extensions during downloads.

Strong naming is a barrier to entry for many new authors of Visual Extensions and provides very marginal value. It requires all the referenced DLLs to be strongly named and the last thing a new extension author wants to be doing is messing around with ildasm.exe.

Developing Visual Studio extensions is hard and the more you can remove these "I have no idea what I'm doing" moments, the better. Signing is an option that (unfortunately) needs to exist but the vast majority of extensions don't need it and it doesn't make sense as a default.