verelpode

My feedback

  1. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
    verelpode commented  · 

    I forgot to mention C# "Shared Projects" (".shproj"). The problem of unused code is amplified by Shared Projects because when we include 2 or 3 Shared Projects in several C# apps, ALL of the classes are included in the final compiled .exe of each app. I wish that the unused classes would be automatically removed from the final .exe's.

    verelpode shared this idea  · 
  2. 57 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Visual Studio IDE » IDE and Editor  ·  Flag idea as inappropriate…  ·  Admin →
    verelpode commented  · 

    The problem of unused code is amplified by C# "Shared Projects" (the ".shproj" project files) because when we include 2 or 3 Shared Projects in several C# apps, ALL of the classes are included in the final compiled .exe of each app. I wish that the unused classes would be automatically removed from the final .exe's.

    verelpode commented  · 

    In addition to finding unused code, I wish that the C# compiler would remove unused code from the final app or .exe file. If you use a large library in an app, but the app uses only a small portion of the library, the entire library is included in the final app anyway. In the past, back in the C++ days, unused functions were automatically stripped out.

  3. 550 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    55 comments  ·  Visual Studio IDE » IDE and Editor  ·  Flag idea as inappropriate…  ·  Admin →

    Hello,

    We’ve begun work on this and are considering changing the default location for new projects to C:\\USERPROFILE\Source\repos. Would this be a reasonable change to address the problem of “clutter” in the Documents folder? This is currently the default for cloned repositories, so all projects would be in a singular default location.

    As well, you still retain the option to change the default if you’d like.

    Allison Buchholtz-Au
    Program Manager – VS IDE

    verelpode commented  · 

    Likewise could we please have an option to change the location of the hidden ".vs" folder that is created in C# project folders? This would make it easier to exclude the ".vs" folder from backups.

    Please note that when backups are UPLOADED to an online service, the file size is significant, and the backup uploads much faster when the ".vs", "bin", "obj" folders are excluded. Temporary files and output files don't need to be backed up, therefore should be stored separately. Thanks for considering it.

    verelpode commented  · 

    I wish we could also change the default location of the build output folders (the folders named "bin\Debug" and "bin\Release" and "obj" that are created as subfolders of a C# project folder). When doing daily backups, the build output folders don't need to be backed up, so backup would be easier and faster if we could move the build output folders to somewhere outside of the project folders.

  4. 703 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    12 comments  ·  Visual Studio IDE » Blend for Visual Studio  ·  Flag idea as inappropriate…  ·  Admin →
    verelpode commented  · 

    Although I agree with import of Photoshop, I think import of Adobe Illustrator files is more important than Photoshop, because Blend/XAML is vector-based and Illustrator is likewise vector-based, whereas Photoshop is primary raster-based with some vector extensions. Likewise strong SVG support is important.

  5. 1,184 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    17 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
    verelpode commented  · 

    Re "Detect unused references in a project" -- I agree, but it should do more than only detecting unused references. I wish that the C# compiler would automatically remove (strip out) unused assembly references and classes from the final app/exe (when compiled for Release not Debug). If you use a large class library in an app, but for example the app uses only 20% of the library, then the entire library is included in the final app/exe anyway. I wish that the final compiled app/exe contained only the references and classes that are truly used in the app, not the entire contents of every class library that I reference in an app.

  6. 240 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  Visual Studio IDE » Project  ·  Flag idea as inappropriate…  ·  Admin →
    verelpode supported this idea  · 
    verelpode commented  · 

    In addition to removing unused references (to assemblies), I wish that the C# compiler would remove unused code/classes/methods from the final app or .exe file. If you use a large library in an app, but the app uses only a small portion of the library, the entire library is included in the final app anyway. I wish that the final compiled app/exe contained only the references and classes that are truly used in the app.

    For example, it is a big maintenance hassle to manually remove 60 unused classes and retain the 5 classes that are actually used in a particular app.

  7. 11,267 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  515 comments  ·  Visual Studio IDE » .NET  ·  Flag idea as inappropriate…  ·  Admin →
    verelpode supported this idea  · 
  8. 4,204 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    39 comments  ·  Visual Studio IDE » IDE and Editor  ·  Flag idea as inappropriate…  ·  Admin →

    Hi thanks for your votes and survey responses. We’ve closed down the survey now and are looking into options that would solve the underlying need that you’ve presented to us. However, due to prioritization of work, we will not be able to release this exact feature in a future update.

    verelpode commented  · 

    Multiple tab rows would also be very useful in Microsoft Edge, in addition to Visual Studio.

  9. 35 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Visual Studio IDE » .NET  ·  Flag idea as inappropriate…  ·  Admin →
    verelpode commented  · 

    Alexander -- I agree. Unfortunately neither C# nor the .NET Framework gives us access to the CLZ (or equivalent) instructions in modern processors. I mentioned the BitScanForward function, which is implemented using the processor's fast intrinsic instruction, but BitScanForward is in the old Win32 C++ API, and so we need the equivalent added to the .NET Framework for C#.

    verelpode shared this idea  · 
  10. 1,811 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    52 comments  ·  Visual Studio IDE » Blend for Visual Studio  ·  Flag idea as inappropriate…  ·  Admin →
    verelpode commented  · 

    I can't believe that Microsoft dropped such an important feature from Blend 2015! It is also quite bad practice to deliver a new version of the product that has LESS functionality than the previous version.

    verelpode supported this idea  · 
  11. 14 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Visual Studio IDE » .NET  ·  Flag idea as inappropriate…  ·  Admin →
    verelpode commented  · 

    Today I was thinking similar to you. Firstly, we all know that immutable objects are very good in some situations. But how to build the immutable object? If the class contains only few properties, then a generally satisfactory solution is to pass all the properties as parameters in the constructor.

    However, this solution is impractical when a class contains many properties. A constructor with 20 parameters is impractical.

    Imagine a source code generation facility that automatically generates (and maintains) mutable "builder" (AKA "factory") versions of selected classes! It would inspect the properties of each immutable class (getter-only properties) and generate a "builder" version with the same properties except with both getter and setter methods in each property.

    It must also support collection properties. The immutable class efficiently stores each list-collection property as a fixed-size array, like this:

    private Something[] _SomeItems;
    public IReadOnlyList<Something> SomeItems { get { return _SomeItems; } }

    Whereas the builder version implements the collection property in a mutable manner like this:

    private List<Something> _SomeItems = new List<Something>();
    public IList<Something> SomeItems { get { return _SomeItems; } }
    // (still no setter, instead use IList.Add() etc.)

    IMPORTANT: I said generate the builder from the immutable class, but consider whether the opposite direction would be better. i.e. should the programmer write the builder version of the class, then the immutable version is auto-generated from the builder class. Or maybe support both directions -- programmer's choice.

    ***** ACTUALLY: The best solution may be that the programmer writes NEITHER the immutable or builder version, rather he/she writes an abstract class or interface that is used as the basis/source to auto-generate both the immutable and builder versions of the class. Perhaps the programmer can optionally override the auto-generation of a particular property implementation in either the immutable or builder class (or both) by supplying a manually-implemented version of that property (in special cases), but the default and usual situation is to auto-generate the implementation. *****

    Alternatively, you could consider some kind of new C# syntax/feature that extends the preexisting "Object Initializers" feature to better support immutable classes:
    https://msdn.microsoft.com/en-us/library/bb384062(v=vs.140).aspx

    (A bad solution: Make a constructor in the immutable class with a System.Dynamic.ElasticObject parameter, then construct the immutable object by reading the contents of the ElasticObject. This is a bad idea because it prevents IntelliSense and compile-time reporting of mistakes. It's also inefficient.)

    See also the following proposal, but I still don't think it's sensible to have a constructor with 20 parameters. The opposite direction would actually be more justifiable (if at all) -- perhaps auto-generate a constructor from properties, but certainly don't auto-generate properties from a constructor.
    http://roslyn.codeplex.com/discussions/543522

    Also related:
    * http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2269104-support-for-immutable-objects
    * http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3265206-auto-properties-readonly-setter-object-initializ
    * http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6573713-add-more-support-for-immutability-to-net-especia
    * http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6573713-add-more-support-for-immutability-to-net-especia

    Thanks for considering it.

  12. 165 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    12 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
    verelpode commented  · 

    We all know that immutable objects are very good in some situations. But how to build the immutable object? If the class contains only few properties, then a generally satisfactory solution is to pass all the properties as parameters in the constructor.

    However, this solution is impractical when a class contains many properties. A constructor with 20 parameters is impractical.

    Imagine a source code generation facility that automatically generates (and maintains) mutable "builder" (AKA "factory") versions of selected classes! It would inspect the properties of each immutable class (getter-only properties) and generate a "builder" version with the same properties except with both getter and setter methods in each property.

    It must also support collection properties. The immutable class efficiently stores each list-collection property as a fixed-size array, like this:

    private Something[] _SomeItems;
    public IReadOnlyList<Something> SomeItems { get { return _SomeItems; } }

    Whereas the builder version implements the collection property in a mutable manner like this:

    private List<Something> _SomeItems = new List<Something>();
    public IList<Something> SomeItems { get { return _SomeItems; } }
    // (still no setter, instead use IList.Add() etc.)

    IMPORTANT: I said generate the builder from the immutable class, but consider whether the opposite direction would be better. i.e. should the programmer write the builder version of the class, then the immutable version is auto-generated from the builder class. Or maybe support both directions -- programmer's choice.

    ***** ACTUALLY: The best solution may be that the programmer writes NEITHER the immutable or builder version, rather he/she writes an abstract class or interface that is used as the basis/source to auto-generate both the immutable and builder versions of the class. Perhaps the programmer can optionally override the auto-generation of a particular property implementation in either the immutable or builder class (or both) by supplying a manually-implemented version of that property (in special cases), but the default and usual situation is to auto-generate the implementation. *****

    Alternatively, you could consider some kind of new C# syntax/feature that extends the preexisting "Object Initializers" feature to better support immutable classes:
    https://msdn.microsoft.com/en-us/library/bb384062(v=vs.140).aspx

    See also the following proposal, but I still don't think it's sensible to have a constructor with 20 parameters. The opposite direction would actually be more justifiable (if at all) -- perhaps auto-generate a constructor from properties, but certainly don't auto-generate properties from a constructor.
    http://roslyn.codeplex.com/discussions/543522

    (A bad solution: Make a constructor in the immutable class with a System.Dynamic.ElasticObject parameter, then construct the immutable object by reading the contents of the ElasticObject. This is a bad idea because it prevents IntelliSense and compile-time reporting of mistakes. It's also inefficient.)

    Thanks for considering it.

Feedback and Knowledge Base