user1jaw

My feedback

  1. 41 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Visual Studio IDE » Extensibility  ·  Flag idea as inappropriate…  ·  Admin →

    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…

    user1jaw commented  · 

    Thank you for your response and highlighting the difficulties. I understand that the problem is very complex, but on the other hand, extensions were supported since at least Visual Studio 2005 - we have 2016 now and it doesn't seem to be any visible improvement in this respect.

    As for mentioned complexities:
    - When something related to the file format changes (like signing mechanism), then code supporting the new format should not replace the old code but new versions of VS should include both.
    I know that it's an example of a simpler case, but in newer versions of VS we can open projects created in older versions of VS, so something similar is needed with extensions.

    - The gallery would probably have to be changed to something like Firefox extensions gallery:
    https://addons.mozilla.org/
    The developer should be able to mark extension as explicitly compatible with some version of VS, explicitly incompatible or none of them (also it would be good if users could report extensions as incompatible). If the extension is not marked as either compatible or incompatible, the gallery should include it in the search results, but with some warning.

    - If some functionality is removed from newer version of VS (e. g. some component has to be installed manually by the user), then when extension tries to use this functionality, something like OperationNotAvailableException() should be thrown, but the extension should still work with functionality which remained unchanged or which is compatible with older functionality.

    I know that all of it is much easier said than done, but again - even when only some specific kind of extensions were compatible with next versions of VS, then it would be much improvement over the current situation. Note that some extensions should be almost certainly compatible with future versions of VS (e. g. text manipulating extensions), yet developers are required to modify them with every new released version. Also, Roslyn refactorings should be usable too - they should work at least when new language features are not used in the code.

    user1jaw commented  · 

    If I could, I'd give nearly all my votes for this suggestion. This is the most annoying issue which makes newer versions of Visual Studio actually worse (in some respects) than older ones. There should be an option for extensions to use older APIs. Of course, there would always be some incompatible extensions, but these should be an exception from the rule. Look at e. g. Firefox - newer versions of this browser are compatible with older extensions by default.

    "So every time there is a new version of VS, there will be fewer extensions, which is not something that should happen."

    Exactly. Type what you want in the Visual Studio Gallery searchbox (e. g. "a") and you'll get the results like this:

    Visual Studio 2010: 3344
    Visual Studio 2012: 2823
    Visual Studio 2013: 2706
    Visual Studio 2015: 2277
    Visual Studio 15: 259

    Now, it can mean what newer versions of VS are so awesome that they need less and less extensions. Or that developers simply can't afford rewriting the extensions every time and the situation is getting worse and worse. For VS 2015 there are about 30% less extensions than for VS 2010. And how about VS 15? I know it's still a Preview version, but such a ridiculous situation discourages people from trying it. I mean, why should you use it for writing software when you can't use your favorite refactorings, code generation tools etc.?

    user1jaw supported this idea  · 
  2. 3,388 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    34 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
    user1jaw commented  · 

    Indeed, even better would be to extend this functionality not only to constructors, but other methods (e. g. Add(T) etc. ). This would give us an option to use real duck typing in C#. Quite a few features of C# work using duck typing (e. g. foreach, collection initializers, LINQ, await and tuple deconstruction in C#7). Would be nice if our classes could use it too!

  3. 111 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Visual Studio IDE » Debugging and Diagnostics  ·  Flag idea as inappropriate…  ·  Admin →
    user1jaw supported this idea  · 

Feedback and Knowledge Base